Skip to content

Updated config is not correctly picked up after re-auth #914

Closed
#943
Closed
Updated config is not correctly picked up after re-auth#914
#943
Assignees
vilmibm
Labels
bugSomething isn't working

Description

@lumaxis
lumaxis
opened on May 13, 2020

Describe the bug

When trying to use gh pr checkout, I was prompted to re-auth to add the read:org scope to the OAuth(?) app's permissions. After successfully completing that flow, the CLI still error'd thinking it's still lacking the required scopes.
A second attempt at the same command worked without any problems

Expected vs actual behavior

  1. Given the CLI OAuth does not have the read:org scope
  2. When using gh pr checkout command to checkout a PR locally
  3. And successfully completing the automatic re-auth flow in the browser to add the missing scope
  4. Then it should correctly continue with the checkout flow

Instead, it failed with an error.

Logs

$ gh pr checkout https://github.com/<org>/<repo>/pull/123
Notice: additional authorization required
Press Enter to open github.com in your browser...
Authentication complete. Press Enter to continue...
graphql error: 'Your token has not been granted the required scopes to execute this query. The 'name' field requires one of the following scopes: ['read:org', 'read:discussion'], but your token has only been granted the: ['repo'] scopes. Please modify your token's scopes at: https://github.com/settings/tokens.'

$ gh pr checkout https://github.com/<org>/<repo>/pull/123
Switched to a new branch 'feature/add-deploy-readme'

Activity

  1. lumaxis
    added
    bugSomething isn't working
    on May 13, 2020

  2. mislav commented on May 13, 2020

    @mislav
    mislav
    on May 13, 2020
    Contributor

    Thank you! This came up in #762 (comment) and I thought it was a fluke, but now I'm convinced that it's because determineBaseRepo creates its own api.Client instance, so we end up with 2 per lifecycle of a command, and when we update the token in memory of one api.Client it stays stale in the 2nd.

    Ref. #786

  3. vilmibm commented on May 13, 2020

    @vilmibm
    vilmibm
    on May 13, 2020
    Contributor

    ah interesting, so it sounds like the solution is just passing a client pointer to determineBaseRepo. that would explain it.

  4. vilmibm commented on May 13, 2020

    @vilmibm
    vilmibm
    on May 13, 2020
    Contributor

    We'll revisit this tomorrow when pairing but this problem persists even with a single apiClient being created in the course of a command run.

  5. vilmibm
    self-assigned this
    on May 13, 2020

  6. vilmibm commented on May 14, 2020

    @vilmibm
    vilmibm
    on May 14, 2020
    Contributor

    After pairing we cleared up some of my confusion around the auth code. I am fixing determineBaseRepo to not create a second apiClient in another PR but can cherry pick it onto something for this bug.

  7. mislav
    closed this as completedin #943on May 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions