Skip to content

docs(architecture): narrow cancellation known-limitation to reflect COW-918 fix #51

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jeffersonBastos merged 1 commit into from
Apr 22, 2026
Merged

docs(architecture): narrow cancellation known-limitation to reflect COW-918 fix #51

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/architecture.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -221,5 +221,5 @@ The block handlers (C1–C4) already run on both mainnet and gnosis. Adding a ne

## Known Limitations

- Cancellation of deterministic generators (TWAP) isn't detected after all parts are discovered. Once `allCandidatesKnown=true`, C1 stops polling — so on-chain removal via `ComposableCoW.remove()` won't be reflected in the status. There's no on-chain event for removals; detecting it would require re-polling completed generators periodically.
- Cancellation of deterministic generators (TWAP) isn't detected after all parts are discovered. Once `allCandidatesKnown=true`, C1 stops polling — so on-chain removal via `ComposableCoW.remove()` won't be reflected in the generator's status, and because the parent is never marked `Cancelled`, its children don't get reconciled either. There's no on-chain event for removals; detecting it would require re-polling completed generators periodically. When C1 _does_ detect cancellation (via `SingleOrderNotAuthed` on an `allCandidatesKnown=false` generator), C2 and C3 cascade the state to children in the next block — API-terminal statuses (`fulfilled` / `unfilled` / `expired`) still win for children that were already traded on the orderbook.
- Aave adapter owner resolution is reactive — `owner_mapping` is written when the adapter appears in settlement, which may be after the conditional order is created. The generator row keeps `resolvedOwner` equal to the adapter address when no mapping existed at insert time; that column is not backfilled when the mapping is inserted later.
Loading