Mount: fix timeout and add distinct exit codes for auth/network failures#2034
Open
tyrielv wants to merge 2 commits into
Open
Mount: fix timeout and add distinct exit codes for auth/network failures#2034tyrielv wants to merge 2 commits into
tyrielv wants to merge 2 commits into
Conversation
tyrielv
force-pushed
the
tyrielv/mount-timeout
branch
from
994c625 to
223b028
Compare
The MountVerb used a single 60s pipe-connect call without process tracking, causing 'GVFS.Mount process is not responding' errors even when the mount process was alive but blocked on network retries. Changes: - MountVerb now passes a process-tracking delegate to WaitUntilMounted (the same mechanism previously added for GVFS.Service automount), enabling fast-fail on process exit and short-interval connect retries instead of a single blocking 60s connect. - Auth/network retry progress is now surfaced in the mount status message visible to the user via GetStatus polling, so they can see issues like '401 Unauthorized, retrying (attempt 2/7)...' and choose to kill the mount early rather than waiting blindly. The pipe-connected GetStatus polling loop is already unbounded (waits indefinitely while mount reports progress), so once the pipe connects, slow network operations no longer cause timeouts — users just see live status updates instead of a frozen 'Mounting...' spinner. Assisted-by: Claude Opus 4.6 Signed-off-by: Tyrie Vella <tyrielv@gmail.com>
tyrielv
force-pushed
the
tyrielv/mount-timeout
branch
from
223b028 to
95cc5ad
Compare
tyrielv
changed the title
tyrielv
force-pushed
the
tyrielv/mount-timeout
branch
from
5d83327 to
726b2e8
Compare
During mount startup, TryInitializeAndQueryGVFSConfig now distinguishes three failure modes with unique process exit codes: - CredentialTimeout (10): git credential fill did not respond within 30 seconds — GCM is likely blocked waiting for interactive auth that nobody is answering (common on headless server machines). - AuthenticationError (9): credentials were provided but the server rejected them (expired PAT, insufficient permissions). - NetworkError (11): non-auth failure contacting the server (timeout, DNS, 5xx errors). Previously all three cases mapped to GenericError (3) or AuthenticationError (9), making it impossible for callers to distinguish 'GCM is hung' from 'bad credentials'. Also skip config query retries when a cache server is already configured locally. The mount will proceed with the fallback cache server on first failure rather than blocking on retries whose results would be discarded anyway. Signed-off-by: Tyrie Vella <tyrielv@gmail.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
tyrielv
force-pushed
the
tyrielv/mount-timeout
branch
from
726b2e8 to
0cff7c0
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A user reported 'Unable to mount because the GVFS.Mount process is not responding' when authentication issues before the mount pipe was opened took more than the 60s we currently wait for the pipe to open. A previous PR already partially addressed this by moving the named pipe opening earlier in the mount process, but we can do more.
Fix
MountVerb now uses process tracking - passes a
MountProcessSnapshotdelegate toWaitUntilMounted, the same mechanism previously added for the GVFS.Service automount path. This enables:We previously implemented process tracking for GVFS.Service (automount), but hadn't incorporated it into regular user-initiated mounts.
Auth/network retry progress surfaced to user - The
ConfigHttpRequestorretry loop now reports failures and retry attempts into the mount progress message (viaonRetrycallback). Users see live status like 'Network: Server returned 401 (Unauthorized), retrying (attempt 2/7)...' instead of a frozen 'Mounting...' spinner. This lets them Ctrl+C early if auth is broken rather than waiting 3+ minutes for retries to exhaust.Distinct exit codes for mount startup failures - New exit codes for
gvfs mount:AuthenticationErrorCredentialTimeoutgit credential fillhung for 30s (GCM waiting for interactive auth on headless machine)RemoteGvfsConfigError/gvfs/configfor non-auth reasons (timeout, DNS, 5xx)Previously the non-auth cases mapped to
GenericError (3), making it impossible to script recovery or diagnose failures in logs.Skip config retries when cache server is local - When a cache server URL is already in local git config,
TryInitializeAndQueryGVFSConfigmakes a single attempt instead of retrying up to 7 times. If it fails, mount proceeds immediately with the fallback cache server. This avoids blocking mount for 30+ seconds on retries whose results would be discarded anyway.30s timeout on credential fill during mount -
git credential fillnow has a timeout during mount startup. If GCM doesn't respond (e.g., blocked on interactive browser auth nobody is answering), mount fails fast with exit code 10 instead of hanging indefinitely.