Skip to content

deepbook: add cancel_live_order(s) graceful cancel APIs (DBU-349)#952

Merged
tonylee08 merged 1 commit intomainfrom
tlee/dbu-349-cancel-live-orders
Apr 8, 2026
Merged

deepbook: add cancel_live_order(s) graceful cancel APIs (DBU-349)#952
tonylee08 merged 1 commit intomainfrom
tlee/dbu-349-cancel-live-orders

Conversation

@tonylee08
Copy link
Copy Markdown
Collaborator

Summary

  • Add cancel_live_order(order_id) and cancel_live_orders(order_ids) on Pool. Both no-op when an id is not in the balance manager's account_open_orders (already filled, cancelled, expired-and-swept, or not owned by this BM), instead of aborting with big_vector::ENotFound like cancel_order / cancel_orders do today.
  • Existing cancel_order / cancel_orders are unchanged — graceful behavior is opt-in via the new functions, no ABI break.
  • Linear: DBU-349

Key decisions

  • Authorization stays strict. Orders in account.open_orders() belong to that BM by construction (state/account.move:161), so the live path still routes through cancel_order and its EInvalidOrderBalanceManager assert. An id owned by a different BM falls through the contains check and is silently skipped — matches the graceful intent without weakening any guard.
  • Local snapshot for the batch variant. cancel_live_orders snapshots account_open_orders once and removes ids from the local copy as it cancels them. This handles duplicate ids in the input vector naturally — the second occurrence misses the local contains check instead of aborting in the underlying cancel_order.
  • Expired-but-not-swept orders are still cancelled. If an order is past its expiry but still in account.open_orders(), the graceful variants route it through cancel_order (which handles expiry inside process_cancel). They do not silently drop expired orders.
  • No new error codes / no new events. Skipped ids are silent — no OrderCanceled event is emitted for them. Successful cancels emit the existing OrderCanceled event via the unchanged cancel_order path.

Test plan

  • cancel_live_order_succeeds_for_live_order — happy path on a single live order
  • cancel_live_order_skips_filled_order — single id that was filled by a crossing taker is silently skipped
  • cancel_live_order_noop_for_unknown_id — never-placed id is a no-op
  • cancel_live_orders_skips_filled_in_batch — mixed batch (one filled, one live); filled is skipped, live is cancelled
  • cancel_live_orders_handles_duplicate_ids[id, id] does not abort on the second pass
  • Existing cancel-family suite (23 tests) still green: test_cancel_orders_*, test_cancel_all_orders_*, test_place_and_cancel_*, test_self_matching_cancel_*

🤖 Generated with Claude Code

Adds `cancel_live_order` and `cancel_live_orders` on `Pool`. Both no-op
when an order id is not in the balance manager's `account_open_orders`
(already filled, cancelled, expired-and-swept, or not owned by this BM),
instead of aborting with `big_vector::ENotFound` like `cancel_order` /
`cancel_orders` do today.

Existing entrypoints are unchanged (no ABI break). Authorization stays
strict: orders in `account.open_orders()` belong to that BM by
construction, so the live path still routes through `cancel_order` and
its `EInvalidOrderBalanceManager` assert.

The batch variant snapshots `account_open_orders` once and removes ids
from the local copy as it cancels them, so duplicate ids in the input
vector miss the second `contains` check instead of aborting.

Tests cover: live cancel, already-filled skip (single + batch),
unknown id no-op, and duplicate ids in the input vector.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Copy link
Copy Markdown
Collaborator

@pei-mysten pei-mysten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@tonylee08 tonylee08 merged commit f831a4f into main Apr 8, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants