fix(orchestrator): suppress warn for filesystem-only memfile resolution#3151
fix(orchestrator): suppress warn for filesystem-only memfile resolution#3151levb wants to merge 1 commit into
Conversation
Filesystem-only snapshots persist no memfile, so Fetch's memfile resolution always failed — spamming the "failed memfile resolution" warn on every fs-only resume, and (under P2P) with a misleading PeerTransitionedError. Gate the warn on the filesystem_only metadata flag: on resolution failure, check the metadata and record a clear sentinel error consumers already tolerate (reboot resume, scheduling metadata) instead of warning. The check runs only on failure, so the common memory-snapshot path never waits on the metadata download. Rootfs untouched.
❌ 2 Tests Failed:
View the top 2 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
There was a problem hiding this comment.
Code Review
Because filesystem-only snapshots do not persist a memfile, they also lack a memfile header in storage. This causes t.memfileHeader.WaitWithContext(ctx) to fail first, setting a generic error on t.memfile and returning early. As a result, the isFilesystemOnly check inside the memfileErr != nil block is bypassed, and the expected errFilesystemOnlyNoMemfile sentinel error is never recorded. To fix this, the isFilesystemOnly check should also be performed when hdrErr != nil in the header resolution block.
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.
| if t.isFilesystemOnly(ctx) { | ||
| if err := t.memfile.SetError(errFilesystemOnlyNoMemfile); err != nil { | ||
| return fmt.Errorf("failed to set memfile error: %w", err) | ||
| } | ||
|
|
||
| return nil | ||
| } |
There was a problem hiding this comment.
Because filesystem-only snapshots do not persist a memfile, they also lack a memfile header in storage. This causes t.memfileHeader.WaitWithContext(ctx) to fail first, setting a generic failed to resolve memfile header error on t.memfile and returning early. As a result, the isFilesystemOnly check inside the memfileErr != nil block is bypassed, and the expected errFilesystemOnlyNoMemfile sentinel error is never recorded. To fix this, the isFilesystemOnly check should also be performed when hdrErr != nil in the header resolution block.
Filesystem-only snapshots persist no memfile, so Fetch's memfile resolution always failed — spamming the "failed memfile resolution" warn on every fs-only resume, and (under P2P) with a misleading PeerTransitionedError. Gate the warn on the filesystem_only metadata flag: on resolution failure, check the metadata and record a clear sentinel error consumers already tolerate (reboot resume, scheduling metadata) instead of warning. The check runs only on failure, so the common memory-snapshot path never waits on the metadata download. Rootfs untouched.