Address review: filter the two rejection paths the sweep missed

Commit

Soph2w ago

nodo found two carriers of server-authored text that the original sweep did not reach, neither of them in that diff — which is likely why.

The best-effort rejection path is the higher-value one. OnRejection is called with the raw cs.Status, stored in s.rejections, and applyRejections turns it into BranchPlan.Reason, which FormatPlanLine prints and which is marshalled as "reason". That path never goes through asRefRejectedError, so sanitizing there did not cover it. It also matters more than an error would: --all-refs turns on BestEffort for sync and bootstrap, so surfacing the server's ng text is the designed behaviour, and a hostile reason was printed as a WARN line and embedded in --json. Filtering happens at the callback now, which is the single point every consumer reads through. IsLeaseFailure and applyRejections only substring-match, so this cannot change how a rejection is classified — the test asserts both directions, that a non-lease reason stays non-lease and a real "stale info" marker still matches after filtering.

report.UnpackStatus was interpolated directly, about six lines above the sibling branch whose unpack failure the previous commit wrapped in sanitizedError. Same function, same kind of text, formatted rather than wrapped, so it needed its own call. Covered end to end through PushPack against a fake receive-pack server reporting a hostile unpack status.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com Entire-Checkpoint: 01M0DBA8KN6ZDB8RPQCTR8GRBF

Checkpoints

Security Review and Vulnerability Fixes

Claude CodeOpus 5.[1m]
View session
Checkpoint 1