[Bug]: Git LFS clone shows "Checking out files · 100% · Stalled" while the download is still progressing#33215

Note

Filed by Claude Opus 5.5 via Claude Code on behalf of @GuardedAirplane. The evidence below comes from existing runs recorded on #27606; it was not rerun for this report.

Before submitting

I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Have stock git-lfs installed (git lfs install) and a network slow enough that one LFS object takes more than ~20 seconds to download (the verification run used an HTTPS forwarding proxy limited to about 1 MB/s).
In the app: Add project → Git URL → https://huggingface.co/openai/whisper-tiny.
Watch the clone progress banner while the LFS objects download.

Expected behavior

While LFS bytes are still arriving, the banner shows that the download is progressing. Stalled appears only when the transfer has actually stopped.

Actual behavior

About 20 seconds in, the banner shows Checking out files · 100% · Stalled even though the download is healthy and bytes are still arriving. In the verification run, the downloaded object grew from 13 MB to 20 MB while Stalled was shown.

The clone does not hang and no data is lost: it finishes normally and the checkout is correct. Only the progress status is wrong.

Likely cause: git's LFS smudge filter prints nothing until a whole file lands, and the clone tracker treats 20 seconds of silence as a stall. GIT_LFS_FORCE_PROGRESS does not help on this path.

Impact

Minor bug or occasional failure: misleading progress. A user cloning an LFS repo is told a healthy clone has stalled and may cancel it.

Version or commit

Reproduced on main @ 5fe18d79ac

Environment

Server: Linux, git-lfs 3.4.1, web client in Chrome, HTTPS LFS behind a ~1 MB/s proxy (independent verification, Oct 31).
Also seen by the PR author with git 2.56 and git-lfs 3.8.1 against a local LFS server throttled to 2 MB/s per connection.
Affects the server clone path. Web and mobile both render the same server-provided progress summary; the observed runs used the web client only.

Logs or stack traces

shell

1	# projectCloneProgressSummary over time, from the PR author's run on main
2	0.0s Checking out files · 33%
3	20.0s Checking out files · 100% · Stalled
4	30.3s [done]

Screenshots, recordings, or supporting files

Before (main): https://github.com/GuardedAirplane/t3code/releases/download/pr-27606-evidence/clone-lfs-before.png
Independent verification with before/after captures: https://github.com/pingdotgg/t3code/pull/27606#issuecomment-6549323566 (verified PR head 5d8d51d; the PR head was later updated to 62bc41a)

Workaround

None needed for correctness; the clone completes if left alone.

Candidate fix and request for triage

Candidate implementation: #27606. With the stock LFS filter, it clones with smudging skipped, then runs git lfs pull with forced progress so bytes are reported as they arrive and the existing stall detection still catches real stops. Other LFS setups keep today's plain clone.

This has not been triaged. Maintainers, please confirm the intended behavior (no Stalled during a healthy LFS download) and whether changing how LFS clones run is an acceptable scope for the fix.