Dead/inaccessible repo in multi-folder workspace: endless 404 retries exhaust the internal 140-call limit, and the log never names the failing repo

[sprintray-yanyifan]

Environment

• Extension version: 0.162.0
• VS Code version: 1.132.0
• OS: Linux x64
• GitHub product: GitHub.com (private org repos, SAML SSO)

Steps to Reproduce

1. Open a multi-folder workspace (or a folder containing nested git clones, e.g. a refs/ directory) where one of the folders' origin remote points to a GitHub repository that no longer exists (deleted or renamed — in my case SprintRay-Software/Rayware-Native, renamed to RaywareNative).
2. Open the GitHub Pull Requests view / let the extension initialize.

Expected Behavior

• The extension fetches the repository once, gets a 404, logs a single, actionable warning that names the failing owner/repo and the workspace folder it came from.
• It then marks that remote as permanently failed (a 404 is not a transient error) and stops retrying it.
• Other, healthy repositories in the workspace are unaffected.

Actual Behavior

• The extension retries the 404 forever (every activation/refresh), logging:

[warning] [GitHubRepository+8] Fetching default branch failed: HttpError: Not Found - https://docs.github.com/rest/repos/repos#get-a-repository

• The repeated retries pile up until the extension's own internal concurrency limiter trips:

[error] [RateLimit] API call count has exceeded 140 concurrent calls.

• Once the limiter is saturated, requests for healthy repositories are blocked too, so the whole PR view fails to load — one dead folder degrades the entire workspace.

Diagnosis notes

• The warning does not say which repository 404'd. With 7 git remotes in the workspace I had to probe each one with gh api repos/<owner>/<repo> by hand to find the dead one. Naming the repo (and folder) in the log would have made this a 30-second fix.
• The exceeded 140 concurrent calls message is the extension-internal limiter, not GitHub's REST/GraphQL rate limit — my account had 4995/5000 core calls remaining while the extension was refusing to work.
• Verified the root cause by moving the two folders whose remotes pointed at the renamed repository out of the workspace: all errors disappeared and PRs loaded normally.

Suggestions

1. Treat 404 on get-a-repository as terminal for that session: log once, skip subsequent retries.
2. Include owner/repo and the workspace folder path in the failure log.
3. Don't let retries for failed repositories consume the shared concurrency budget of healthy ones (or add exponential backoff for repeated identical failures).

Possibly related: #4813, #8621 (internal rate limit flooding), #7835, #6095 (unactionable "Not Found" logs).