session/filesync: byte-level output progress, no ContentHasher (fixes AS LOCAL panic)

[gilescope]

syncTargetDiffCopy set NotifyHashed without a ContentHasher. fsutil wraps every incoming file in a hashedWriter whenever NotifyCb is set and DEREFERENCES the hasher to do it (diskwriter.go, newHashWriter), so a nil hasher is a nil-pointer panic, not a no-op - and SAVE ARTIFACT ... AS LOCAL crashed outright:

panic: runtime error: invalid memory address or nil pointer dereference
fsutil.newHashWriter(0x0, ...) diskwriter.go:285

The session attachables run in the CLI, which is why it showed up there, not in buildkitd. Introduced by the verbose-progress rewire: the forked fsutil had a VerboseProgressCB hook that needed no hasher; stock fsutil offers only NotifyHashed, and the port adopted the hook without its precondition.

The real problem was the wrong hook. This is the OUTPUT path (writing built artifacts to the user's local disk); it computes no cache key and reads no digest - the callback was pure progress. But NotifyHashed is fsutil's HASHING per-file hook: it would MultiWriter every received byte through a hasher for a digest nobody reads, on every AS LOCAL, even once the nil-deref is fixed.

So switch to ReceiveOpt.ProgressCb: cumulative received bytes, per packet, NO hasher. It gives LIVE transfer feedback - which is what an output copy actually wants - and the panic is structurally impossible because no ContentHasher is ever constructed. The earthly-specific sync-target API carries a func(int, bool) progress callback instead of an fsutil.ChangeFunc (ExportEntry.OnReceiveFile -> OnReceiveProgress).

Not the Filter hook: it is an inclusion filter, applied in two places (receive.go destWalker + doubleWalkDiff) and sometimes with an empty stat, so it double-counts. Not a discard/no-op ContentHasher: it works, but it abuses the hashing hook for a non-hashing need. ProgressCb is the hook fsutil actually provides for this.

Trade-off: byte-level aggregate instead of per-file lines. On this path the per-file lines were VerbosePrintf (debug-only) anyway; the normal-level UX is a throttled byte summary, which ProgressCb feeds directly - and byte-level is the better signal for a slow network copy.

Verified: SAVE ARTIFACT AS LOCAL of a 60 MiB artifact succeeds, exact bytes on disk, live byte progress, no hashing. It panicked 100% of the time before.

Assisted-by: Claude:claude-opus-4.8 claude-code

[github-actions]

⚠️ Are we earthbuild yet?

Warning: "earthly" occurrences have increased by 29 (13.36%)

📈 Overall Progress

Branch	Total Count
main	217
This PR	246
Difference	+29 (13.36%)

📁 Changes by file type:

File Type	Change
Go files (.go)	❌ +26
Documentation (.md)	➖ No change
Earthfiles	➖ No change

---

Keep up the great work migrating from Earthly to Earthbuild! 🚀

💡 Tips for finding more occurrences

Run locally to see detailed breakdown:

./.github/scripts/count-earthly.sh

Note that the goal is not to reach 0.
There is anticipated to be at least some occurences of earthly in the source code due to backwards compatibility with config files and language constructs.

[gemini-code-assist]

Code Review

This pull request replaces the per-file file-receive callback (fsutil.ChangeFunc) with a cumulative byte-level progress callback (func(int, bool)) across the file synchronization pipeline. This change avoids unnecessary hashing overhead and potential nil-pointer panics during artifact saving. The review feedback suggests naming the parameters of the anonymous progress callback function (e.g., func(bytes int, done bool)) across all signatures to improve code readability and self-documentation.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.