Repository navigation
fix: History: stop a finished top-up's claim from landing on the next one - #77
Open
piggydoughnut wants to merge 7 commits into
Open
piggydoughnut wants to merge 7 commits into
piggydoughnut wants to merge 7 commits into
Conversation
…ng the claim Fixes #62
|
pr77-getcash.paseo · logs |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
Stops a finished top-up's claim from being recorded onto the next top-up's record, so each history row keeps its own amount.
Note
Records already corrupted on paseo stay as they are (claimed is immutable by design; no migration)
Why
Two different top-ups (50 and 20) showed the same 50 amount in history. When a top-up settles,
the surface polls the worker's claim every 2s for up to 200s — and disposing the session never
stopped that loop. When the claim finally landed,
onClaimProgressrecorded it against themutable
foregroundRef, i.e. whatever request the buyer had started since, and the record'sclaimedslot is first-write-wins, so the wrong amount stuck permanently.app/stores/session.ts: claim progress is pinned to the request the world was built for(
claimRef), never the current foreground.lib/coinage.ts: the session's existingstopflag is threaded intocreateCoinageHandoff;dispose()now ends the settle wait instead of leaving a zombie poll.How it was tested
tests/claim-handoff.test.ts: a settle disposed mid-wait ends withoutrecording a claim or reporting "crediting".
pnpm typecheck,pnpm typecheck:packages,pnpm format:check,pnpm buildall pass.check on getcash.paseo after deploy: start a second top-up with a different amount while the
first is still claiming — history must show both amounts. Records corrupted before the fix
stay as they are (
claimedis immutable by design; no migration), so judge only by newtop-ups.
Checklist
pnpm typecheckandpnpm typecheck:packagespasspnpm testpassespnpm format:checkpasses (runpnpm formatto fix)pnpm buildsucceeds (andpnpm build:workerif the worker changed)Co-Authored-By:trailers in commits (they fail the paritytech CLA check)Related
Closes #62