go mod tidy: drop stale lantern-box v0.0.106 hashes - #587
Conversation
#586 bumped go.mod to v0.0.107 but left v0.0.106's hashes in go.sum, so both versions were present with valid hashes. That is the condition that let a release binary resolve a superseded version despite go.mod declaring the newer one: on 2026-04-13 a build shipped lantern-box v0.0.58 while go.mod said v0.0.65, silently disabling Reflex for every user. gomobile bind is the tool that has done this. Ran go mod tidy on a clean checkout. My working tree had untracked files that made tidy exit early on the original bump, which is how the stale entries survived. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RVgb2MDpZ4wpH6fywKC2hE
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (1)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Follow-up to #586, which I got wrong.
What happened
#586 bumped
go.modtolantern-box v0.0.107but left v0.0.106's hashes ingo.sum, so main currently carries both with valid hashes:Why it matters
This is the precise condition that lets a build resolve a superseded version even though
go.moddeclares the newer one — the stale entry still verifies, so nothing complains. On 2026-04-13 that shipped a release withlantern-box v0.0.58compiled in whilego.modsaid v0.0.65, silently disabling Reflex for every user.gomobile bindis the tool that has done this.Given #586 exists specifically to carry a client-info fix out to clients, a build that quietly resolves v0.0.106 would deliver the release without the fix it was cut for.
How it got through
My working tree had untracked files (
cmd/meek-probe,cmd/meek-fronts-dump, and a missingkindling/meek) that madego mod tidyexit early — after writing itsgo.modchange but before pruninggo.sum. I then "verified" againstgit stash, which does not stash untracked files, so the contamination survived the check and I read the failure as pre-existing.Worth noting for anyone reading #586's description: my claim there that
go mod tidyis broken on main was wrong — it succeeds on a clean checkout. Thecmd/lanternbreakage I mentioned is real and tracked (cmd/lantern/lantern.go:170callsipc.NewClient()against a signature taking(context.Context, backend.Options)and returning two values), but it is unrelated to this.Verification
Run on a clean
git worktreeoforigin/mainwith no untracked files:go mod tidy— exit 0, removes exactly the two stale linesgo mod verify— all modules verified🤖 Generated with Claude Code
https://claude.ai/code/session_01RVgb2MDpZ4wpH6fywKC2hE