Repository navigation
fix(filler): set the update block and time of an offer that turns invalid - #243
Merged
Merged
Conversation
…alid The filler turned an offer invalid with a write of the state column alone. Each other state write of the offer processor also sets updated_at_block and updated_at_time, so a reader of /v1/offers with a sort or a filter on the update time never saw an offer turn invalid. The transfer and burn trace handlers record the newest block with a moved asset, because the commit listener gets no block. The invalid write takes its block and time from that record. A commit of several blocks during catch-up uses the newest of them. The write that turns an offer pending again stays a write of the state alone. A new update time there makes a restored offer look like a new one to a reader that selects pending offers by update time.
robrigo
force-pushed
the
fix/eng-2440-offer-invalid-write-timestamps
branch
from
October 13, 2026 20:38
4526963 to
83fb862
Compare
There was a problem hiding this comment.
🟢 Approval recommended
The implementation matches the documented batch semantics and is covered by focused integration tests.
0 open findings
What changed in this PR
Updates invalidated offers so API consumers can detect state changes through update-time sorting and filtering.
Changes:
- Records the latest asset movement block per commit batch.
- Updates invalidated offers’ block and timestamp.
- Adds integration coverage and release notes.
| File | Description |
|---|---|
src/filler/handlers/atomicassets/processors/offers.ts |
Tracks movement metadata and applies it during invalidation. |
src/filler/handlers/atomicassets/processors/offers.integration.test.ts |
Tests transfer, burn, restoration, and closed-offer behavior. |
CHANGELOG.md |
Documents the public response change. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Merged
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.
The filler turned an offer invalid with a write of the
statecolumn alone. Each other state write of the offer processor also setsupdated_at_blockandupdated_at_time. So a reader of/v1/offerswith a sort or a filter on the update time never saw an offer turn invalid, and a client had to read each offer again to learn of the change. Tracking: ENG-2440. Lane S.The
logtransferandlogburnassettrace handlers now record the newest block with a moved asset, because the commit listener gets no block. The write to INVALID takes its block and time from that record. When the filler commits several blocks in one transaction during catch-up, both values are those of the newest block of that transaction with a transfer or a burn, not of the exact block of each move. The write that turns an offer pending again stays a write of the state alone, so a restored offer keeps the block and time of its invalidation. A new update time on that write would make a restored offer look new to a reader that selects pending offers by update time.The change is visible in the API: an offer that turns invalid now moves up in a
/v1/offersread withsort=updated, and the two fields of its response change at that moment. The change has no migration. TheCHANGELOG.mdentry sits under## [2.7.0]because the values of a public response change.Validation.
pnpm lintandpnpm check-typespass.pnpm testpasses with 607 tests and 37 pending, the counts of the previous run.pnpm test:integration:ciagainst PostgreSQL 17 passes with 841 tests, against 837 before. Of the 4 new cases, the 3 that read the two fields after a transfer, after a burn, and after a restore failed against the old processor. The fourth proves that an accepted, declined, or cancelled offer stays unchanged when its asset moves, and it passes before and after.