The replayLegitimateRetryWindow constant (22h -> 24h -> 22h across three reviews)
was the wrong discriminator for 'original/retry vs expired-key duplicate' in the
stale-pending sweep: it is a row-age PROXY for 'when did THIS sweep replay the
key'. Each review flipped it because the true cutoff is the sweep's own replay
moment — a payment created at/after the sweep's ReplayPaymentByKey call can only
be the sweep's expired-key creation, and a payment created before it is the
original or a legit same-key retry, INDEPENDENT of Square's unverified ~24h key
retention (square_http_client.go:626).
- reconcileStalePaymentByKey now captures replayAt := clock.Now() immediately
before the replay call and threads it through
- replayRevealsNewCharge / replayWithinLegitimateWindow compare the replayed
payment's created_at against replayAt (upper bound) instead of
row.CreatedAt + a fixed constant; the 5m lower-bound clock-skew tolerance is
unchanged
- replayLegitimateRetryWindow constant and its rationale block removed (dead);
replayRescueLowerBoundSkew docstring updated to reference replayAt
- sweep_test comments updated to document the new discriminator + why the
constant approach flip-flopped (21h/22h/24h) and is now unnecessary
The keyed-replay tests (retry at 21.5h rescued; 25h-after-row auto-refunded)
still pass and now pin the correct, retention-window-independent behavior.
26/26 backend packages.
popertots
ecef5da516