What's wrong
GitBranchStateCache/Admission/AdmissionGate.cs classifies a failed git ls-remote probe by substring-matching its stderr:
AuthenticationMarkers (lines 44-52) contains the bare strings "403" and "401", checked at line 128.
NotFoundMarkers (lines 63-67) contains the bare "not found", checked at line 135.
Git's stderr almost always echoes the full repository URL. Any URL with those digits in it (a repository called issue-401, game-403, an org or project name, or a port) therefore matches the authentication marker, whatever the actual failure was.
Repro
git ls-remote --heads https://nonexistent-host.invalid/studio/game-401.git prints:
fatal: unable to access 'https://nonexistent-host.invalid/studio/game-401.git/': CONNECT tunnel failed, response 502
Its lowercase form contains "401", so the classification is 401 "The upstream refused this credential" instead of the 502 / unreachable result.
That git output was captured from a real run. The classification step follows directly from the ordinal Contains check at line 128; it has not been run through AdmissionGate end to end.
Why it matters
A DNS failure, proxy failure or upstream outage for such a repository tells the client its credential was refused. Users then rotate tokens or chase auth problems that don't exist. A 401 also makes git clients prompt for credentials again instead of retrying.
Suggested fix
- Match git's own phrasing, such as
"returned error: 401", "returned error: 403", "authentication failed" and "could not read username", rather than bare status digits.
- Alternatively, remove the repository URL from the output before matching.
- Tighten the bare
"not found" marker in the same way; "could not resolve host" output must not be read as not-found.
Acceptance criteria
- A tunnel or DNS failure for a URL containing
401 or 403 classifies as 502 / unreachable.
- Real
returned error: 401 / 403 output still classifies as 401.
- Tests cover both cases.
What's wrong
GitBranchStateCache/Admission/AdmissionGate.csclassifies a failedgit ls-remoteprobe by substring-matching its stderr:AuthenticationMarkers(lines 44-52) contains the bare strings"403"and"401", checked at line 128.NotFoundMarkers(lines 63-67) contains the bare"not found", checked at line 135.Git's stderr almost always echoes the full repository URL. Any URL with those digits in it (a repository called
issue-401,game-403, an org or project name, or a port) therefore matches the authentication marker, whatever the actual failure was.Repro
git ls-remote --heads https://nonexistent-host.invalid/studio/game-401.gitprints:Its lowercase form contains
"401", so the classification is 401 "The upstream refused this credential" instead of the 502 / unreachable result.That git output was captured from a real run. The classification step follows directly from the ordinal
Containscheck at line 128; it has not been run throughAdmissionGateend to end.Why it matters
A DNS failure, proxy failure or upstream outage for such a repository tells the client its credential was refused. Users then rotate tokens or chase auth problems that don't exist. A 401 also makes git clients prompt for credentials again instead of retrying.
Suggested fix
"returned error: 401","returned error: 403","authentication failed"and"could not read username", rather than bare status digits."not found"marker in the same way;"could not resolve host"output must not be read as not-found.Acceptance criteria
401or403classifies as 502 / unreachable.returned error: 401/403output still classifies as 401.