Skip to content

fix(desktop): classify git credential prompt failures as authentication - #5561

Open
TheSeydiCharyyev wants to merge 1 commit into
block:mainfrom
TheSeydiCharyyev:fix/repo-availability-credential-error
Open

fix(desktop): classify git credential prompt failures as authentication#5561
TheSeydiCharyyev wants to merge 1 commit into
block:mainfrom
TheSeydiCharyyev:fix/repo-availability-credential-error

Conversation

@TheSeydiCharyyev

Copy link
Copy Markdown
Contributor

Summary

  • classify git's could not read Username / could not read Password as authentication instead of unknown
  • the Projects repo panel now says "Repository access failed — Buzz could not authenticate with this repository" instead of "Repository unavailable — try again or contact the project owner"

This is suggestion 3 from #5348. It is a subset, not the whole issue — see Scope below.

Why

projectRepoUnavailableReason matches 401, 403, authenticat, authoriz, permission denied and access denied. git's credential-prompt failure looks like none of those:

fatal: could not read Username for 'https://relay.example': Device not configured

So it fell through to unknown, and the panel blamed the project owner for a problem that is local to the user's machine.

The path is easy to reach. git-credential-nostr needs the credential-protocol authtype capability, which arrived in git 2.46. On an older git the helper exits silently, no credential is supplied, and git prints the error above. The relay's 401 never reaches the classifier, so no existing pattern can match.

Scope

Only the message classification. #5348 also suggests version-aware git resolution and a typed error from the snapshot command; both sit in src-tauri and are larger changes. The reporter wrote "any subset", so I took the one that is self-contained.

Worth saying plainly: this improves the message, it does not fix the underlying setup. A user on git 2.39 still cannot clone. But "Buzz could not authenticate" points at the right thing, and unknown did not.

Validation

  • RED to GREEN: the new test fails on unmodified projectRepoAvailability.ts (expected 'unknown' to equal 'authentication') and passes with the change. The other 9 tests in the file are unaffected in both runs.
  • pnpm --filter buzz test — 4,605 passed
  • pnpm --filter buzz exec tsc --noEmit
  • pnpm --filter buzz check — biome, file sizes, px-text, pubkey truncation

I also checked the classifier by hand against four strings before writing the fix: both credential-prompt variants returned unknown, while The requested URL returned error: 403 returned authentication and remote: Repository not found returned missing. Only the credential path was wrong.

`projectRepoUnavailableReason` had no pattern for git's `could not read
Username/Password` error, so a failed credential lookup fell through to
`unknown`. The Projects repo browser then showed "Repository unavailable —
try again or contact the project owner" for what is a local credential
problem, which sends the user after the wrong thing.

This is reachable on any git older than 2.46: `git-credential-nostr`
requires the credential-protocol `authtype` capability and exits silently
without it, so git reports `could not read Username` and never reaches the
relay's 401 that the existing patterns match on.

The panel now shows "Repository access failed — Buzz could not authenticate
with this repository."

Refs block#5348

Signed-off-by: Seydi Charyyev <seydi.charyev@gmail.com>
@TheSeydiCharyyev
TheSeydiCharyyev requested a review from a team as a code owner August 11, 2026 10:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant