[Amperstrand]

Stacked on #507 (same files, trivial context). Fixes #498 (scoped).

What

• The 30s timeout branch no longer drops the still-running Receive: reconcileLateReceive adopts its outcome — a late success grants the session the customer paid for (visible via GET /usage); a late failure is logged with the mint identity.
• Timeout notice copy now says the payment may still complete and to check usage before retrying (no more "please try again" invitation to double-pay).
• receiveTimeout package var + openGateForSession test seam (repo's standard stub conventions).

Why

Every slow-mint crossing of the deadline consumed the token with no session, no record, and a message telling the customer to pay again — value loss on each occurrence (#498).

Scope

Closes the common case (process survives the timeout). The crash-during-window case is the durable payment record (#502); reconcileLateReceive documents itself as crash-unsafe pending that.

Verification

• Full merchant suite green under -race (224.8s, testenv).
• New tests: late-success grants (waits on the gate stub, race-clean), late-failure grants nothing.

[Amperstrand]

Verification: PR #511 (late-Receive reconciliation, #498)

Tested as-is at head 0d319076ccaa788ae2067ee5e1a2c2767bf98583 (mergeable, stacked on #507's branch fix/500-pending-proof-reclaimer, 5 commits behind main). The mechanism itself is correct and verified under race: the late-completion grant rides the exact inline grant path, in-process exactly-once holds, and the concurrency division of labor with #507 is confirmed from this diff. But the head tree fails the repo's pre-PR gate in src/cli (inherited from the stack's base, identical to what #507's verification found), and the CHANGELOG entry is missing — so this needs the same small stack-level revision before it can land.

What I ran

• make go-battery from the repo root: fails at module src/cli — go: updates to go.mod needed; to update it: go mod tidy (exit 2); root module green (ok … 14.9s).
• Per-module battery (gofmt -l / go vet / go build / go test -race -count=1 -tags testenv) on the modules the diff touches or reaches: src/merchant green end-to-end (ok 220.217s), src/tollwallet green (ok 34.867s), src/cli fails vet and build with the go.mod error above.
• gonuts sweep over all 16 go.mod files (only 4 reference gonuts): src/merchant / src / src/tollwallet pin v0.12.1 ✓; src/cli still carries v0.11.2 // indirect ✗ — the chore(deps): bump gonuts-tollgate v0.11.2 → v0.12.0 (melt/swap-retry counter reservation + #480 landing) #506 gap class, present in this tree via the base branch.
• Fix proof: cd src/cli && go mod tidy (flips gonuts indirect to v0.12.1) makes vet+build green there; reverted afterwards.
• Focused race on the PR's own scenario: go test -race -count=10 -tags testenv -run TestPurchaseSessionLateReceive → 20/20 PASS (2 tests × 10), ok 8.186s, exit 0.
• No cloud-lab run: no lane exercises PurchaseSession against a slow mint (the lab has renewal_e2e.sh and run-keyset-rotation.sh only); Priority: P1 — ambiguous-outcome class at the TollGate layer. Independent of gonuts fixes. #498's slow-mint proxy lane doesn't exist yet and is fairly follow-up work, not verification of this diff.

Reconciliation semantics — grants the session late, via the inline path

reconcileLateReceive blocks on the same buffered channel the abandoned goroutine feeds, then on success runs identically to the inline success arm: calculateAllotment(res.amount, mint) → grantSessionAccess. That's the best arm of the choice — the customer paid, they get service, visible via GET /usage; no refund-path complexity imported from #403.

Collisions land correctly because grantSessionAccess is additive: AddAllotment on an existing session does Allotment += amount (with a start-time reset) — a late grant stacking on a retry that already succeeded lands as a top-up through the same path as any second payment, and a gate-open failure rolls back to the snapshotted previous session. Same-token retry is safe by mint-side serialization: the two Receives race on the same proofs, exactly one can win; the loser surfaces as ErrTokenAlreadySpent (inline error notice or late-failure log), so exactly one grant per payment in every interleaving. A late failure only logs (mint identity + error) — no state change, no grant.

Idempotency and crash window — honest, explicitly scoped

In-process exactly-once is airtight: the channel is buffered size 1 with exactly one consumer — the inline select if the result arrived in time, otherwise the single reconcile goroutine spawned only in the timeout arm; the goroutine's panic-recover also routes into the channel, so the reconciler always gets a terminal result. Across a daemon restart inside the window the completion is lost — accepted with rationale, documented at the code site ("crash-unsafe by design — the durable version is the payment-record saga (#502)") and in the PR body; #502 (open, P1, business-transaction record) is the right home for the durable version. The PR does not pretend otherwise, which is the correct shape for a P1 stopgap.

Ordering vs #507 and #475 — no new lock interaction; interplay verdict confirmed

I re-derived #507's interplay verdict from this diff and confirm it: reconcileLateReceive calls no wallet methods at all — it touches neither the pending bucket nor the wallet mutex; the only wallet interaction remains the original Receive call (pre-existing, covered by v0.12.1's serialized counter derivation). Lock-wise the reconciler holds nothing while blocked on the channel, takes sessionMu briefly inside AddAllotment/snapshotSession, and shells out to ndsctl with no lock held — no cycle with the reclaimer's wallet-mu sweeps, no shared state, no starvation (the reclaimer's 60 s ticker and this per-timeout goroutine are independent). #475-class rebuilds: sessions are in-memory per-Merchant with no persistence anywhere in the package, so a rebuild between timeout and late completion lands the grant in the old merchant's map — a pre-existing class for any in-flight grant (same family as #507's stale-goroutine note), not a defect this PR introduces.

Tests — the race is pinned, one assertion is too loose

TestPurchaseSessionLateReceiveGrantsSession pins the exact #498 interleaving: deadline shrunk to 50 ms, Receive completes at 250 ms — asserts the timeout notice went to the customer and the completion landed and the eventual state (GetSession().Allotment > 0) and the gate opened; the failure arm asserts nothing is granted. Race-clean at -count=10. One gap: the response assertion is Contains("timed out"), which the old copy also satisfies — assert "may still complete" so #498's copy requirement (message must say the payment may still complete and to check usage) is actually pinned.

Findings

Blocking

1. Head tree fails make go-battery at src/cli — identical to finding 1 on feat(merchant): pending-proof reclaimer — ambiguous send/melt outcomes self-heal (#500) #507: the stack's dep-bump commits (75a566c, 320896b) updated src/, src/merchant, src/tollwallet but not src/cli, which replace-pins ../merchant/../tollwallet and still carries gonuts v0.11.2 indirect + stale go.sum. Not introduced by this commit, but it's the tree this stack would merge. Fix is go mod tidy in src/cli (verified above) — ideally in chore(deps): bump gonuts-tollgate v0.11.2 → v0.12.0 (melt/swap-retry counter reservation + #480 landing) #506 so the whole stack inherits it.
2. No CHANGELOG entry. User-visible twice over: late payments now grant the paid-for session, and the timeout notice copy changed. One bullet under [Unreleased] → ### Fixed (which sits above the already-tagged [v0.6.0-alpha3] — the entry must not land under the alpha3 section), linking the PR per house style.

Strongly recommended

3. "Fixes Priority: P1 — ambiguous-outcome class at the TollGate layer. Independent of gonuts fixes. #498" will auto-close the issue, but Priority: P1 — ambiguous-outcome class at the TollGate layer. Independent of gonuts fixes. #498 is only partially delivered. The issue's acceptance criteria include crash-restart reconciliation (durable record) and the slow-mint cloud-lab lane; both are explicitly deferred here to Priority: P1 — the TollGate-level business-transaction record; generalizes the still-open #403 into a mechanism. #502. Reword to "Part of Priority: P1 — ambiguous-outcome class at the TollGate layer. Independent of gonuts fixes. #498 (common case)" — or the maintainer reopens it post-merge — so the durable-saga remainder keeps a tracking issue.
4. Strengthen the notice-content assertion to "may still complete" (see Tests).

Notes

• The timeout-arm comment says a late failure is logged "with the same classification the inline path uses" — it's actually logged raw (mint identity included, which suffices for manual classification) without running the inline branches (MarkUnreachable, token-spent, rate-limit). Harmless since the customer is already answered; just wording.
• res, ok := <-ch; if !ok is unreachable (nothing closes ch) — fine to keep, just defensive.
• The receiveTimeout/openGateForSession test seams match the repo's stub conventions (valve.runNdsctl); production behavior of openGateForSession is unchanged by the func→var conversion, and its only caller outside tests (grantSessionAccess) is unchanged. Single commit, no AI attribution, no drive-by changes.

Disposition

request-changes — both blockers are stack-level hygiene, not reconcile-mechanism defects: (1) the src/cli go mod tidy (land it in #506 so #507 and #511 inherit it), (2) the [Unreleased] CHANGELOG bullet, plus ideally the #498 linkage rewording and the copy assertion. The mechanism itself verified green under race and I'd flip to land-with-followups (follow-ups: #502 durable saga, slow-mint cloud-lab lane) as soon as those land.

[Amperstrand]

Stack-level follow-ups resolved: cli tidy via #515, CHANGELOG entry added at branch head (bb7cf679). Remaining recommendations: reword the auto-close footer to Refs #498 (durable-saga criteria live in #502) and pin the updated notice copy in the assertion. Mechanism already race-proven — land-with-followups.

[Amperstrand]

Integration verification against this branch in the cloud-lab (frozen-mint scenario, docker pause):

What works: the scoped fix is sound — unit coverage (late-success grants / late-failure grants nothing) plus live boot is clean, and the recovery path is correct: after the mint thawed, the exact token that lived through the wedge paid 200 in 0.1 s, no residue.

Adjacent gap found (not this PR's scope, filing separately): with a wedged/frozen mint, payment requests never reach the receiveTimeout wrapper. Goroutine dumps (SIGQUIT, two in-flight payments, minutes deep):

HandleRootPost → PurchaseSession (merchant.go:482) → SwapFeeSats
→ mintKeysetFees → GetMintActiveKeyset → getMintActiveKeysetFallback → client.go:134

The fee precheck's keyset fetch blocks first: each HTTP call is 30 s-timeout × up to 5 attempts with backoff, and GetMintActiveKeyset chains two endpoints — a wedged mint stalls the precheck for ~5+ minutes, so the "fall through and let Receive classify" path (which needs the calls to return) never fires and the 30 s timeout below it is unreachable. Customer sees a multi-minute hang instead of the new notice. Fix shape candidates: bound the precheck with a short context deadline and reuse the existing error fall-through; or serve SwapFeeSats from the wallet's cached keyset (InputFeePpk is already in the local DB — the network fetch looks avoidable entirely).

Worth noting for review ordering: this doesn't weaken the PR's claims (its window is Receive-start-to-deadline, unit-proven); it's the next window over.

[Amperstrand]

Mergeability note: GitHub's cache has reported this PR CONFLICTING for hours while git merge-tree against current main proves the tree CLEAN at every pushed head (including after an empty-commit push to force recomputation, c5c50596). All content blockers from the verification pass are resolved (cli tidy via #515, CHANGELOG at head). If the UI still refuses, merging via the API with a fresh recompute or a one-line revert-and-reapply of the entry hunk will clear it — the code itself is conflict-free and race-proven.

[Amperstrand]

Live validation of the late-reconciliation claim (cloud-lab, this PR stacked with #532's precheck budget — previously your coverage was unit-level only):

step	result
payment with the mint frozen	400 in 33.0 s, payment-processing-timeout, "may still complete…" copy
mint thawed 9 s later	PurchaseSession: late Receive completed … amount=50 — granting the paid-for session → 50 steps converted (3,000,000 ms), gate opened, MAC authorized
replay of the same token	400 / 21023 — no double grant

Without #532 this scenario cannot reach your timeout wrapper (the fee precheck parks first — see #525); the two compose exactly as designed.

One integration note for your rebase: your branch predates #486, and merging it with current main silently drops TollWallet.AcceptMint from tollwallet.go (textual overlap in the file) — the root module stops compiling (w.inner.AcceptMint undefined). Worth rebasing before review completes.

[Amperstrand]

Evidence pass (unattended run) — request-changes: the branch tip does not compile.

go vet ./... in src/tollwallet fails:

gonuts_wallet.go:261:17: w.inner.AcceptMint undefined
(type *TollWallet has no field or method AcceptMint)

The branch pins gonuts-tollgate v0.12.1 — the same tag main pins (verified both go.mod files) — and v0.12.1's TollWallet has no AcceptMint method. The new delegation (GonutsWallet.AcceptMint) targets an API that exists in no released tag this branch declares: it needs either a newer gonuts release (retarget + refreshed go.sum) or different wiring. The merchant suite cannot run past this (module dependency), so the reconciliation logic is unverified-by-build at tip.

Stack hygiene: the branch carries 6 unique commits — a duplicated dependency pair (the v0.12.0/v0.12.1 bumps that already landed on main differently via #506/#515), the #500 reclaimer, the #511 fix, its changelog entry, and a mergeability-recompute trigger. That duplication is why the PR diff balloons to AGENTS.md/README/workflow files. Recommend: rebase onto current main, drop the duplicated dep commits (keep main's pins), and let the diff shrink to the real surface — the pending-proof reclaimer (+78/+98), the late-receive test (+167), and the reconciliation wiring — then rebase the AcceptMint call against whatever tag actually ships it.

The design shape (a reclaimer that self-heals ambiguous send/melt outcomes + late-Receive reconciliation) is the right skeleton for #498's class — but it needs to compile before the logic can be credited.

[Amperstrand]

Extensive-test pass (per the critical-but-high-risk protocol: test, don't merge).

Headline: the branch does not build against current main. tollwallet fails vet/compile at gonuts_wallet.go:261 — w.inner.AcceptMint undefined (type *TollWallet has no field or method AcceptMint). Root cause: this branch's TollWallet refactor predates #486 (merged) and drops the AcceptMint surface that Merchant.AdmitReachableMints now calls. The PR's CONFLICTING status was the textual symptom; this is the semantic one — none of its tests are runnable until it rebases (the full make go-battery on this tree dies at the same line, EXIT=2). Fix on rebase: restore the AcceptMint passthrough in the refactored TollWallet (one method), then the suites below can actually run.

What I could verify without building — the design, against the repo's own fund-safety doctrine:

• pendingProofReclaimer resolves ambiguous outcomes via mint-reported proof states — reconciles, never blindly retries (spent-at-mint proofs stay pending and surface as the operator's manual-reconciliation signal, not a silent retry). That is exactly the AGENTS.md rule for ambiguous swap/melt results.
• The capability is discovered by type assertion on a deliberately narrow interface instead of growing WalletPort and the sidecar wire protocol — right call; backends that can't resolve ambiguity degrade to a logged skip.
• Boot-delay + minute sweep; the no-pending fast path is one in-memory bucket read.

Against current main this PR is much smaller than it looks: +434/−39 across 8 files (the earlier 4.6k-line footprint was against its old base — the overnight wave absorbed its workflow churn). That materially lowers its risk profile once it compiles.

Test plan ready to execute the moment it rebases and builds: full make go-battery; merchant + tollwallet race suites; its two new test files (purchasesession_late_receive_test.go, pending_proof_reclaimer_test.go); the cloud-lab payment lanes incl. a frozen-mint scenario (per its own verification notes). I'll run the full pass on request after the rebase lands.

Disposition: do not merge — blocked at compile; rebase + restore AcceptMint, then re-request the extensive pass.

[felixfelix-bot]

Review — CHANGES REQUESTED at head c5c505961c5bfa22d6bd65a93955c6d76e9541d4 (all evidence re-derived first-hand this run: fresh clone, rev-parse verified; gate 2.5 cold audit by an independent cross-family reviewer confirmed verdict + findings).

The reconciliation mechanism itself is sound. The late grant rides the exact inline success path (calculateAllotment → grantSessionAccess, src/merchant/merchant.go:667-674); in-process exactly-once holds — the buffered channel has exactly one consumer (the inline select, or the reconciler spawned only in the timeout arm; the panic-recover send can't double-send); AddAllotment is additive under sessionMu, so a late grant stacking on an already-succeeded retry lands as a top-up; the reconciler never re-submits the token (no derivation-range re-use); a late failure only logs; no lock is held across the ndsctl call; the crash window is honestly scoped to #502. gofmt clean on both touched modules; gitleaks 8.21.2 over the true stack diff (a99d983..c5c5059): no leaks.

But the tree this PR would merge does not build, does not merge cleanly, and now competes with a different interim policy already on main:

1. [BLOCK] The branch does not compile — root cause is in this PR's own stack, not in main moving underneath. go vet ./... from src/tollwallet (and every module importing it, including src/merchant under -tags testenv): src/tollwallet/gonuts_wallet.go:261:17: w.inner.AcceptMint undefined (type *TollWallet has no field or method AcceptMint). Stack commit 1e7107f rewrote tollwallet.go and dropped TollWallet.AcceptMint + mintMu (both present in the merge-base via #486) while leaving the GonutsWallet delegation at gonuts_wallet.go:261. Blast radius: accept_mint_test.go and merchant_late_mint_test.go also fail to build in every default configuration — none of this PR's (or the reclaimer's) tests can run at head. Control at origin/main: vet clean, tollwallet suite ok 32.165s. Fix in this PR: restore the AcceptMint surface + mintMu locking in the rewritten TollWallet (or split the reclaimer commits out) — a plain rebase will not bring the method back.

2. [BLOCK] Real merge conflict whose resolution is a policy decision. git merge-tree --write-tree origin/main pr-511 → exit 1, CONFLICT (content): src/merchant/merchant.go. The conflict is the timeout arm itself: main has since adopted the opposite interim behavior (#548): payment-outcome-unknown notice, an operator receiveReference, explicit "Do not send this e-cash note again — a second attempt will be refused" copy, grant-nothing, with the late-grant journal explicitly deferred — and src/merchant/late_receive_notice_test.go on main pins that no-grant contract. This branch auto-grants and tells the customer "may still complete. Check your usage before retrying." Resolving the markers means choosing one design (and updating main's test to match); you cannot keep both.

3. [RISK] The #486 regression is semantic, not just textual. Branch src/merchant/merchant.go:206 (AdmitReachableMints) still calls tollwallet.AcceptMint(...), but the rewritten Receive reads w.acceptedMints with no lock (main: mintMu-protected read) while the health tracker appends at runtime — the exact data race #486's mintMu closed. Whatever design wins, the locking must come back with the method.

4. [RISK] The PR body's verification claim is stale at head. "Full merchant suite green under -race (testenv)" is not reproducible at c5c5059 — the merchant package fails to build under testenv because its tollwallet dependency does not compile. The run was real at the earlier pre-stack-move head (documented in your 09-22 comment); re-run and re-state it after the build is fixed.

5. [NIT] CHANGELOG.md:87 — the new entry drifted into the tagged, released [v0.6.0-alpha4] section ([Unreleased] at line 11 is empty on this branch). Belongs under [Unreleased].

6. [NIT] src/merchant/purchasesession_late_receive_test.go:90,135 — Contains("timed out") is satisfied by the old copy too; pin whichever notice copy survives finding 2 (today that's contested between this branch and main).

7. [NIT] PR body "Fixes #498 (scoped)" — auto-closes #498 on merge while its durable criteria live in #502 (both open). Refs #498 keeps the tracking honest.

No CI evidence exists for this head (GitHub check-runs: 0; ngit kind-9842: no results) — a documented absence, not a pass.

Disposition: fix the AcceptMint surface in-PR, decide the timeout-arm policy against main's #548 (I'd argue the auto-grant here is the better end-state for the customer — it is what #548's own comment says the journal should eventually do — but it must be a deliberate supersession, updated tests and all), move the CHANGELOG entry, then re-request review.

[felixfelix-bot]

CHANGES REQUESTED at head c5c505961c5bfa22d6bd65a93955c6d76e9541d4 — formal review posted alongside; this is the summary. All evidence re-derived first-hand this run (fresh clone, rev-parse verified); independent gate-2.5 cold audit confirmed verdict and findings (2 corrections incorporated).

One line: the late-Receive reconciliation mechanism is sound and arguably the better customer end-state, but this PR's own stack deleted TollWallet.AcceptMint (branch doesn't compile), the timeout-arm conflict with main's #548 is a policy choice, and the CHANGELOG entry landed in a released section.

Findings: 2×[BLOCK] (compile break from stack commit 1e7107f — not fixable by rebase alone; merge conflict = competing timeout-arm designs), 2×[RISK] (#486 locking regression; stale "suite green" verification claim in the PR body), 3×[NIT] (CHANGELOG section, test copy assertion, Fixes→Refs #498).

Evidence: go vet FAIL gonuts_wallet.go:261:17 (control at origin/main clean, suite ok 32.165s); git merge-tree exit 1 (src/merchant/merchant.go); branch tests not runnable at head — recorded as such, never claimed green. gofmt clean; gitleaks 8.21.2 on a99d983..c5c5059: no leaks. No CI evidence for the head (check-runs 0, ngit kind-9842 no results) — documented absence, not a pass.

[Amperstrand]

Technical review (evidence pass) — PR head c5c505961c5bfa22d6bd65a93955c6d76e9541d4 (stacked on fix/500-pending-proof-reclaimer, which is not main; the branch is 34 commits behind main).

The change itself — reconcileLateReceive adopting the outcome of a Receive that outlived the response deadline, a late success granting through the shared grant path, honest crash-unsafety scoping to #502 — is well built, and I verified it green (details below). But the branch cannot land as it stands: the head does not compile, the stack it sits on merged somewhere other than main, and main has since landed #558, which rewrote the exact same deadline branch with different semantics and pinned them with tests. Three blockers, then the good parts.

The head does not build

At c5c505961c5bfa22d6bd65a93955c6d76e9541d4, go build ./... from src/merchant (and src/tollwallet) fails:

../tollwallet/gonuts_wallet.go:261:17: w.inner.AcceptMint undefined
(type *TollWallet has no field or method AcceptMint)

Cause: the branch carries cherry-picks of #507's commits, and the reclaimer pick 1e7107feea791c64f4703a386190a745dc8325c0 resolved src/tollwallet/tollwallet.go to the pre-#486 file — it deletes TollWallet.AcceptMint and the mintMu field — while gonuts_wallet.go:259-262 still delegates to the method. The merge base (a99d983a) has the method and origin/main has it, so this branch removes a merged fix and breaks the default (!cdk_wallet) build of two modules. Fix: drop the stale picks (615adbf4, ea21f6ca, 1e7107fe) and rebuild the branch on a base that already contains their content.

Where this PR actually sits

The base branch fix/500-pending-proof-reclaimer is #507's head branch, but #507 merged into deps/gonuts-v0.12.0 (2026-09-22, merge commit 2239211), not into main. So the reclaimer machinery this branch duplicates (PendingBalance/ReclaimPendingProofs on TollWallet, pending_proof_reclaimer.go) is not on main at all, and GitHub's CONFLICTING state here is the cherry-pick criss-cross, not a real content conflict. The PR needs a deliberate retarget: onto deps/gonuts-v0.12.0's successor into main if that chain lands first, or onto main directly once it carries the reclaimer — and then the duplicated commits vanish from the diff (the PR's own delta is a clean 4 files: merchant.go, lightning.go, the new test, CHANGELOG.md).

#558 landed on the same lines after this PR opened

While this branch sat, #558 (3249d0973999937e9129b2b3cfbdc81dda2740cb, merged 2026-09-24) took the same #498 window from the other direction: it is deliberately log-only — recordLateReceiveOutcome consumes the very channel reconcileLateReceive wants, the notice became payment-outcome-unknown with a reference fingerprint and an explicit "Do not send this e-cash note again", and the behavior is pinned by src/merchant/late_receive_notice_test.go and late_receive_outcome_test.go (untagged, so the CI lane runs them). main's deadline comment explicitly reserves granting for the future journal.

That makes the rebase a design merge, not a textual one:

• Notice copy directly contradicts. This PR's "Check your usage before retrying" (merchant.go:554-555) invites a resubmit-after-check; fix(payment): record the outcome of a Receive that outlived its deadline #558's forbids it, for the fund-safety reason this repo cares about: if the mint took the note, the retry is refused as already-spent and the value is gone — the exact confiscation Priority: P1 — ambiguous-outcome class at the TollGate layer. Independent of gonuts fixes. #498 describes. With your auto-grant, fix(payment): record the outcome of a Receive that outlived its deadline #558's "reload this page in a couple of minutes" becomes true, so keep its no-resubmit guidance + reference and drop the retry invitation; the late_receive_notice_test.go pins will otherwise fail or, worse, get weakened.
• One channel, two consumers. The rebase should compose: recordLateReceiveOutcome keeps the durable log-with-reference, and the grant (your part) runs after the record. An in-memory grant as an interim ahead of the Priority: P1 — the TollGate-level business-transaction record; generalizes the still-open #403 into a mechanism. #502 journal is defensible — it strictly dominates dropping the value — but that tradeoff should be stated against fix(payment): record the outcome of a Receive that outlived its deadline #558's merged stance, and the operator procedure fix(payment): record the outcome of a Receive that outlived its deadline #558 added to docs/operator-guide.md needs updating to say the router now grants late completions itself.

What I verified of the change itself

To separate the stack breakage from the PR's own logic, I grafted #486's AcceptMint back into tollwallet.go at the head (verification shim only, not proposed) and ran: go build, go vet, gofmt clean; go test -race -count=1 -tags testenv . in src/merchant green, 234.6s, matching your claim (224.8s), including both new tests. The grant path is the shared one — grantSessionAccess → AddAllotment extends the allotment under sessionMu with snapshot/restore on gate failure — so a late grant and a subsequent on-time purchase compose instead of clobbering, and the goroutine is race-clean against the sessions map. openGateForSession as a package-level var matches the valve.runNdsctl convention. Test scoping is right (unit, testenv && !cdk_wallet, same tags as merchant_token_flow_test.go), no new dependencies, no token material in the new log lines, and the CHANGELOG.md entry is present and styled correctly.

Two smaller items for the rebase:

• The late-failure arm only logs (merchant.go:661-664); the inline path also calls mintHealthTracker.MarkUnreachable for non-token-spent failures. Either feed the tracker or drop "same classification the inline path uses" from the comment — a mint that fails at t=35s is exactly the one the tracker should hear about.
• In purchasesession_late_receive_test.go:71-77, t.Cleanup blocks unconditionally on <-gateCalled; if the grant path regresses, the suite hangs to the 10-minute go-test timeout instead of failing. Make it a select with a deadline.

And one PR-body fix: it says "Fixes #498 (scoped)", but your own changelog commit (d795e865) correctly says "Refs #498 rather than Fixes — the durable-saga criteria remain open in #502". Once retargeted to main, "Fixes" would auto-close a P1 whose durable-record criteria this PR knowingly leaves open. Change the body to Refs #498.

Disposition

request-changes — (1) rebuild the branch so it compiles: drop the stale #507 cherry-picks that revert #486's AcceptMint; (2) retarget onto the branch that actually carries the reclaimer into main; (3) rebase as a deliberate composition with #558: keep the recorder + reference + no-resubmit notice, layer the grant on top, update the operator procedure, and say explicitly why an in-memory grant is the right interim ahead of #502. The reconciliation logic itself is in good shape — this is rebase-and-decide work, not a redesign.

[Amperstrand]

Closing in favor of a fresh rework. The review found this head does not build (the #486 cherry-pick reverted TollWallet.AcceptMint while gonuts_wallet.go still calls it), the branch stacks on fix/500-pending-proof-reclaimer whose content merged into a deps branch rather than main, and #558 has since landed a different design for the same timeout path (record + no-resubmit guidance). A late-Receive reconciliation is still worth building on post-#558 main — the review's design-merge guidance (record and grant, keep the no-resubmit notice, update the operator guide) is the starting point for the rework. The PR's own logic was verified sound under -race with only the AcceptMint shim, so the rework is mostly mechanical on a correct base.