fix: include counterparty (zero address) as 3rd context row in addOrder/removeOrder#2779
fix: include counterparty (zero address) as 3rd context row in addOrder/removeOrder#2779thedavidmeister wants to merge 6 commits into
Conversation
…er/removeOrder (#2619) The entask post-context for addOrder4 and removeOrder3 only had two rows (orderHash, msg.sender). The spec requires a third row for the counterparty address; because these are order-management operations (not trades) the counterparty is always the zero address. Add `bytes32(uint256(uint160(address(0))))` as that third row and test it. Pre-pins 0.1.7 deploy constants (RaindexV6 address changes, all other contracts unchanged). REQUIRES redeploy at land — testProdDeploy* and testIsStartBlock* / testNetworksJson* will be red until the new RaindexV6 is deployed and build-start-blocks.sh is run. Co-Authored-By: Claude <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 58 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
📝 WalkthroughWalkthroughRaindexV6 add/remove post actions now pass order hash, caller, and zero address in their post-task context. A new test checks ChangesRaindex V6 context and release metadata
Sequence Diagram(s)sequenceDiagram
participant RaindexV6AddOrderEnactTest
participant RaindexV6
participant LibRaindex
RaindexV6AddOrderEnactTest->>RaindexV6: checkAddOrder(...)
RaindexV6->>LibRaindex: doPost(orderHash, post, [orderHash, msg.sender, address(0)])
LibRaindex-->>RaindexV6AddOrderEnactTest: order-counterparty() resolves to address(0)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
Regenerate arb-contract pointer files and update 0.1.7 pre-pin constants. RaindexV6 bytecode change causes arb contracts to deploy at new addresses since they embed the new RaindexV6 address in their deployment parameters.
…ct-per-file static check Merge origin/main (0.1.12) into branch. Resolves conflicts in: - src/concrete/raindex/RaindexV6.sol: keep PR's 3-row context (orderHash, msg.sender, address(0)) for addOrder4/removeOrder3 post-hooks - src/lib/deploy/LibRaindexDeploy.sol: take main's published 0.1.7-0.1.12 constants, add 0.1.13 pre-pin for this PR's new RaindexV6 bytecode - src/generated/*.pointers.sol + crates/test_fixtures/abis/: keep HEAD (new bytecode from this PR) - foundry.toml: bump version to 0.1.13 The merge brings in main's one-contract-per-file fix (PR #2731/#2749) which resolves the rainix-sol/static check failures. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
test/concrete/raindex/RaindexV6.addOrder.entask.t.sol (1)
205-225: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winMirror this regression on
removeOrder3.This PR fixes both order-management flows, but the new regression only exercises
addOrder4. A matching remove-order entask test would keep the second call site from drifting back to the old 2-row context.src/concrete/raindex/RaindexV6.sol (1)
379-386: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDeduplicate the 3-row post-context builder.
These two entrypoints now hardcode the same matrix while the shared helper still represents the old 2-row shape. Keeping the context contract in two places makes this easy to drift again.
♻️ Proposed refactor
- LibRaindex.doPost( - LibBytes32Matrix.matrixFrom( - LibBytes32Array.arrayFrom( - orderHash, bytes32(uint256(uint160(msg.sender))), bytes32(uint256(uint160(address(0)))) - ) - ), - post - ); + _doOrderPost(orderHash, address(0), post); ... - LibRaindex.doPost( - LibBytes32Matrix.matrixFrom( - LibBytes32Array.arrayFrom( - orderHash, bytes32(uint256(uint160(msg.sender))), bytes32(uint256(uint160(address(0)))) - ) - ), - post - ); + _doOrderPost(orderHash, address(0), post);function _doOrderPost(bytes32 orderHash, address counterparty, TaskV2[] calldata post) internal { LibRaindex.doPost( LibBytes32Matrix.matrixFrom( LibBytes32Array.arrayFrom( orderHash, bytes32(uint256(uint160(msg.sender))), bytes32(uint256(uint160(counterparty))) ) ), post ); }Also applies to: 407-414
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/concrete/raindex/RaindexV6.sol` around lines 379 - 386, The post-context matrix is duplicated in the RaindexV6 entrypoints, while the shared helper still reflects the old shape. Update RaindexV6 to centralize this 3-row context construction in a single internal helper such as _doOrderPost, and have both entrypoints call it with the appropriate counterparty so LibRaindex.doPost and the LibBytes32Matrix/LibBytes32Array assembly stay in one place.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/concrete/raindex/RaindexV6.sol`:
- Around line 379-386: The post-context matrix is duplicated in the RaindexV6
entrypoints, while the shared helper still reflects the old shape. Update
RaindexV6 to centralize this 3-row context construction in a single internal
helper such as _doOrderPost, and have both entrypoints call it with the
appropriate counterparty so LibRaindex.doPost and the
LibBytes32Matrix/LibBytes32Array assembly stay in one place.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: c693ebc8-03eb-4b9a-9e16-b4039564bdc2
⛔ Files ignored due to path filters (4)
src/generated/GenericPoolRaindexV6ArbOrderTaker.pointers.solis excluded by!**/generated/**src/generated/GenericPoolRaindexV6FlashBorrower.pointers.solis excluded by!**/generated/**src/generated/RaindexV6.pointers.solis excluded by!**/generated/**src/generated/RouteProcessorRaindexV6ArbOrderTaker.pointers.solis excluded by!**/generated/**
📒 Files selected for processing (5)
crates/test_fixtures/abis/RaindexV6.jsonfoundry.tomlsrc/concrete/raindex/RaindexV6.solsrc/lib/deploy/LibRaindexDeploy.soltest/concrete/raindex/RaindexV6.addOrder.entask.t.sol
…rom merged source The merge-update (step 3d) pulled main's source back into the PR but did not regenerate src/generated/RaindexV6.pointers.sol. The generated file still carried bytecode compiled from the PR's original source (which had the OrderNoSources / OrderNoHandleIO source-count check removed to match an older rainlang version). After the merge the source has those checks again, so the etched-bytecode mock tests now expect them to fire — but the stale RUNTIME_CODE etched at RAINDEX_DEPLOYED_ADDRESS lacked them, causing testAddOrderWithoutCalculationsReverts (and friends) to fail with "next call did not revert as expected". Fix: re-run script/build-meta.sh → forge script BuildPointers.sol → forge build → script/build.sh → forge fmt to regenerate the pointers, update the 0_1_13 pinned constants in LibRaindexDeploy to the new address and codehash, and refresh crates/test_fixtures/abis/RaindexV6.json. testProdDeploy* / testIsStartBlock* / testNetworksJson* remain red (WAITING-DEPLOY): the new RaindexV6 must be deployed before they pass. Co-Authored-By: Claude <noreply@anthropic.com>
|
Producer note: HAND-OFF (three prior 3b attempts, latest 2026-07-04, checks still red). Three distinct causes: (1) copy-artifacts + 9 codehash/runtime-code test fails: the 2026-07-04 regen covered RaindexV6 pointers only — the arb-contract pointers (GenericPool*/RouteProcessor*) are still stale; fix is a FULL ./build.sh run with ALL regenerated artifacts staged. (2) 5 testProdDeploy* + 3 isStartBlock + networks.json/subgraph.yaml: WAITING-DEPLOY (bytecode-changing PR, routine pre-merge deploy). (3) rainix-sol static + rs-static: rainix's new no-ignored-tests gate bans vm.skip, and the flagged vm.skip lines exist on raindex MAIN too (test/lib/deploy/*.t.sol) — an org-level collision that will red main's own next static run; needs an org decision (allow-list or rework those skips), not a branch fix. Per one-attempt-per-check back-off I am not pushing again. |
|
🤖 ai:producer |
thedavidmeister
added
the
ai:ready
|
🤖 ai:vetter |
…-counterparty-context
thedavidmeister
added
ai:reject
|
🤖 ai:vetter |
1 participant
Summary
addOrder4andremoveOrder3populate a post-hook entask context with two rows:orderHashandmsg.sender. The spec requires a third row for the counterparty address; for order-management operations the counterparty is alwaysaddress(0).bytes32(uint256(uint160(address(0))))as the third row in thematrixFromcall for both functions.testAddOrderCounterpartyIsZeroAddressverifies the new third context slot is the zero address.REQUIRES redeploy at land — RaindexV6 bytecode changes, so
testProdDeploy*will be red until it is deployed.testIsStartBlock*/testNetworksJson*/testSubgraphYamlAddresswill also be red untilscript/build-start-blocks.shis run against the new deployment address.Closes #2619
Co-Authored-By: Claude noreply@anthropic.com
Summary by CodeRabbit
Bug Fixes
Chores
0.1.13.