[Tyrie Vella (tyrielv)]

Problem and Context

An HTTP response can return its headers promptly, then stop delivery of body data. VFS for Git uses ResponseHeadersRead, so the request timeout does not bound subsequent body reads. A stalled clone or prefetch can therefore wait indefinitely and never reach the retry policy.

A long transfer does not necessarily indicate a stall. Existing logs do not distinguish a slow transfer from a pending read without progress.

Changes

• Add a 60-second deadline to each pending response-body read, including error bodies. Exclude disk writes and pack processing.
• Add gvfs.read-timeout-seconds. Zero disables the body-read deadline. Caller cancellation remains active.
• Load the complete retry configuration through LoadFromGitConfig in every production consumer. Reuse the configuration during authentication and download initialization.
• Warn and use per-field defaults for invalid or unreadable configuration. Preserve valid fields, active mount snapshots, and explicit command overrides.
• Preserve known HTTP statuses, credential rejection, cache fallback, and cancellation through object-copy and retry paths. Keep the fixed anonymous 401 message.
• Emit progress reports every 30 seconds after the first body read. Include byte progress, pending-read state, current and maximum read waits, bounded cache identity, and final outcomes.
• Correlate pack events and retry summaries through response and request IDs. Use sample sequence numbers to order delayed reports.
• Keep diagnostic writes outside the read-state lock. Make body diagnostics best-effort, including unexpected failures. After a diagnostic failure, disable further reports for that response. Attempt one warning. The read result and cleanup remain unchanged.
• Before retry, wait for pending pack finalization tasks after a failed read. Retain completed pack timestamps and report concurrent finalization failures.
• Return exit code 12 (CloneSucceededPrefetchFailed) when clone succeeds but synchronous prefetch fails. Print a prefetch-only retry command. A requested mount failure takes precedence and returns its own failure code.
• Add unit tests for deadlines, slow transfers, zero-disable behavior, numeric boundaries, and configuration consumers. These tests also assert completed-body handling, credential rejection, cancellation, cleanup, diagnostic failures, and continued reads.
• Add functional tests for stalled clone requests. These tests assert timeout diagnostics, retry recovery, and retry exhaustion through the CLI.
• Add functional tests for post-clone prefetch failure. These tests assert exit code 12, the recovery command, a valid HEAD, and mount-failure precedence.
• Add functional tests for a stalled CLI prefetch and invalid retry configuration. These tests assert the configured deadline, timeout logs, continued mount operation, remount success, and startup warnings.
• Document the deadlines, configuration ranges, fallback behavior, diagnostic fields, prefetch recovery, and ownership of offloaded prefetch.

The read-wait measurements include managed scheduling delay. They distinguish outstanding reads from consumer work, but they do not prove a server or network cause.

Known gaps and deliberate decisions

• Whole-clone recovery — Network steps retain per-request retries. This change does not add whole-clone retries or same-directory restart. Those features need failure classification, compatible-option checks, and protection for existing work. No follow-up PR is linked.
• Background prefetch — gvfs.trust-pack-indexes=false keeps its existing background behavior. Exit 0 confirms process launch, not prefetch completion.

[YingyHuang]

[Claude] Clone still has no retry at the operation level; only individual requests retry (MEDIUM)

File: GVFS/GVFS/CommandLine/CloneVerb.cs (not in diff) Lines: TryClone 480–537, CreateClone 685–694, 725–728 (master)

Problem:

This PR stops stalled body reads from hanging, which is a real improvement. But the only retries are per request: a stall is retried up to gvfs.max-retries times, then reported as a failure. Clone has no retry of its own. If the network is unstable for longer than one request's retry budget, for example several 60s stalls on the commit pack or on info/refs, gvfs clone fails. The user then has to clean up the partial enlistment and run clone again, which is exactly the transient-failure experience this PR is meant to improve.

Evidence:

• CloneVerb.Execute → GetRetryConfig(..., FetchAndCloneTimeoutMinutes) → TryAuthenticateAndQueryGVFSConfig → TryClone → QueryInfoRefs / TryDownloadCommit / TryDownloadRootGitAttributes. Each step returns new Result(errorMessage) on failure, and nothing loops around them.

• The only retries are in RetryWrapper.Invoke (IsHandlableException: IOException, HttpRequestException, RetryableException) and in GitObjects.TrySendProtocolRequest / HandleProtocolException.

• The new functional test (PrefetchVerbTests) covers a stalled prefetch. No test covers a stalled or transient clone.

Suggestion:

Add a bounded retry around the network-bound clone steps. Retry only transient failures, and leave auth failures, missing branches and filesystem errors alone. For example:

C#

// CloneVerb.TryClone
const int MaxCloneStepAttempts = 3;
GitRefs refs = null;
for (int attempt = 1; attempt <= MaxCloneStepAttempts && refs == null; attempt++)
{
    refs = objectRequestor.QueryInfoRefs(this.SingleBranch ? this.Branch : null);
    if (refs == null && attempt < MaxCloneStepAttempts)
    {
        tracer.RelatedWarning(
            new EventMetadata { { "Attempt", attempt } },
            "info/refs query failed after per-request retries; retrying clone step");
        Thread.Sleep(TimeSpan.FromSeconds(RetryBackoff.CalculateBackoffSeconds(attempt + 1, 60, 2)));
    }
}

Apply the same pattern to TryDownloadCommit in CreateClone. Alternatively, make clone restartable in the same directory so re-running gvfs clone resumes. At a minimum, add a clone functional test with a stalled or erroring server and a line in docs/troubleshooting.md saying that gvfs.max-retries and gvfs.read-timeout-seconds apply to clone.

[Nathan Baird (ShiningMassXAcc)]

No significant introduced correctness issue found in the reviewed code. Holding approval pending integration validation.

Medium - Merge readiness: This head currently conflicts with master. Please resolve or rebase and rerun validation against the current target before merge; the existing green run does not establish that the conflict resolution is correct.

Medium (nonblocking) - Differential coverage: The exact-head CI run passes, including the stalled-prefetch deadline and mounted invalid-config tests, but I could not find a changed-line coverage report. Please link differential coverage for the new timeout, cancellation, ownership, and retry branches, or document the remaining coverage gaps in the PR description. This is nonblocking, not evidence that these lines are uncovered.

[Tyrie Vella (tyrielv)]

Note

🤖 Machine-drafted reply, reviewed and approved by Tyrie Vella.

Clone's network steps already use the request retry budget. I kept that budget. An outer loop multiplies the retry budget.

The new functional tests exercise a stalled info/refs request through gvfs clone, including recovery and retry exhaustion. If clone succeeds but synchronous prefetch fails, exit code 12 distinguishes that result. The command prints a prefetch-only retry command. A mount failure takes precedence.

Whole-clone retry and same-directory restart remain outside this change because they need failure classification and safeguards for an existing enlistment.

[Keith Klein (KeithIsSleeping)]

[KeithBot]: 🟡 Medium · Reliability — Cancelled hydration aborts shared blob download; other ProjFS reads can hang

Body reads now honor the request's CancellationToken, but GVFSGitObjects.TryDownloadAndSaveObject runs one shared download per SHA under the first caller's token. Cancelling that caller mid-body (e.g. its process is killed) fails every coalesced waiter: a second ProjFS GetFileData for the same blob is never completed, so that reader hangs, and a joined git read-object request gets DownloadFailed. At the merge base both waiters succeed.

Evidence:
Scratch NUnit fixture: real GVFSGitObjects + GitObjectsHttpRequestor against a loopback server streaming the object in 64-byte chunks every 50 ms, plus the real WindowsFileSystemVirtualizer on MockVirtualizationInstance; GetFileData commands 1 and 2 for one SHA, then OnCancelCommand(1) mid-body.

> GVFS.UnitTests.exe --test=GVFS.UnitTests.Windows.Virtualization.CoalescedCancelRepro
head: RESULT projfs ... command2Completed=False completions=[] cancelledEvents=2
base: RESULT projfs ... command2Completed=True completions=[2:Ok] cancelledEvents=1
head: RESULT direct secondIsNamedPipe=True ... second=EXCEPTION TaskCanceledException
base: RESULT direct secondIsNamedPipe=True ... second=RETURNED Success

Fix:
In GVFSGitObjects.TryDownloadAndSaveObject, restart the download instead of inheriting another caller's cancellation (add before the existing finally):

catch (OperationCanceledException) when (!cancellationToken.IsCancellationRequested)
{
    this.TryRemoveInflightDownload(objectId, lazy);
    return this.TryDownloadAndSaveObject(objectId, cancellationToken, requestSource, retryOnFailure);
}

_{🤖 KeithBot · 1/3 models · verified locally}

[Keith Klein (KeithIsSleeping)]

[KeithBot]: ⚠️ 1 issue · iteration 1 (14b635f)

1. 🟡 Medium Cancelled hydration aborts shared blob download; other ProjFS reads can hang

Validated: ✅ PR unit fixtures, head + merge base · ✅ Full GVFS.UnitTests suite at head · ❌ Coalesced cancel repro, head vs base · ⚠️ Loopback transport/pack/culture probes · ✅ Build of all PR-touched projects · ⏭️ CLI functional tests (clone/prefetch)

_{🤖 KeithBot · claude-opus-5.5, gpt-6.1-sol, gemini-4-argon · reply on a thread to dispute}