Add integration tests for clearing/taking dead orders#2733
Add integration tests for clearing/taking dead orders#2733thedavidmeister wants to merge 1 commit into
Conversation
Adds end-to-end coverage in crates/integration_tests for the best-effort no-op behaviour of takeOrders4 and clear3 against a dead (removed) order, exercising the real RaindexV6 over a LocalEvm. - test_take_orders_dead_order_is_noop: removeOrder3 kills an order, then takeOrders4 against it succeeds, emits exactly one OrderNotFound (sender=caller, owner, orderHash) and no TakeOrderV3, and returns zero totalTakerInput/totalTakerOutput (also asserted via a static call). - test_take_orders_dead_order_skipped_live_order_taken: a [dead, live] batch skips the dead order (one OrderNotFound naming the dead hash) while still taking the live order (one TakeOrderV3 with input/output = 2). - test_clear_dead_order_is_noop: clear3 with one dead side succeeds, emits OrderNotFound for the dead owner/hash and returns early so neither ClearV3 nor AfterClearV2 is emitted. Test-only; no contract changes. Each assertion checks exact event counts, field values and returned totals, so a regression that reverts on, double counts, or silently fills a dead order is caught. Fixes #624 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 33 minutes and 33 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Fixes #624 — adds integration-test coverage in
crates/integration_testsfor clearing and taking against dead/expired orders, asserting the best-effort no-op /OrderNotFoundbehaviour. Test-only; no contract changes.What the issue wanted
Tests for
clear3andtakeOrders4against dead orders. The contract treats a dead order as a best-effort no-op (emitOrderNotFound, skip/return early) rather than reverting, so a stale or removed order can't brick a bulk clear/take. There was no end-to-end coverage of this over a liveLocalEvm—crates/integration_testsonly had the twopost_tasktests.What this adds
Three
#[tokio::test]s that drive the real deployedRaindexV6on aLocalEvm. An order is killed viaremoveOrder3(after whichorderExistsreturnsfalse/sOrders[hash] == ORDER_DEAD):test_take_orders_dead_order_is_noop—takeOrders4against a single dead order succeeds (no revert), emits exactly oneOrderNotFound { sender = caller, owner, orderHash }, emits noTakeOrderV3, and returns zerototalTakerInput/totalTakerOutput(also asserted via a staticcall).test_take_orders_dead_order_skipped_live_order_taken— a[dead, live]batch: exactly oneOrderNotFound(naming the dead order's hash) and exactly oneTakeOrderV3; the live order's fulloutputMax = 2is filled at ratio 1 (taker input/output = 2). Proves the dead order is skipped while the live one is still taken.test_clear_dead_order_is_noop—clear3with one dead side succeeds, emitsOrderNotFoundfor the dead owner/hash, and returns early so neitherClearV3norAfterClearV2is emitted.Verification
cargo test -p raindex_integration_tests: 5 passed, 0 failed (3 new + 2 pre-existing, all green; no env/RPC/deploy-dependent failures in this suite).cargo fmt -- --check: clean. No new warnings.1→2, taker input2→3, dead owneralice→bob) and confirmed all three FAIL with the real on-chain values in the diagnostic (left: 1 / right: 2, owner0xf39f… vs 0x7099…, etc.), then reverted. The pre-existing tests stayed green throughout. So the assertions catch a regression that reverts on, double-counts, or silently fills a dead order — not just "it runs".🤖 Generated with Claude Code