From 5e60419bbe3b5faa7074d3a515141de9bb6509a5 Mon Sep 17 00:00:00 2001 From: Jefferson Bastos Date: Wed, 22 Apr 2026 18:25:09 -0300 Subject: [PATCH] docs(architecture): narrow cancellation limitation to reflect COW-918 Clarify that the deterministic-cancellation limitation is specifically about the allCandidatesKnown=true blind spot (C1 stops polling, so the parent is never marked Cancelled, so the cascade never fires). When C1 does detect cancellation on an allCandidatesKnown=false generator, C2 and C3 now reconcile children in the next block, with API-terminal states preserved for children that were already traded. --- docs/architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture.md b/docs/architecture.md index f7c11cd..ff52682 100644 --- a/docs/architecture.md +++ b/docs/architecture.md @@ -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.