fix(DK): allow recurring DK #2159
Conversation
❌ Deploy Preview for kleros-v2-testnet-devtools failed. Why did it fail? →
|
WalkthroughUpdates DisputeKitClassicBase.createDispute to reuse an existing active local dispute for a given coreDisputeID (resetting dispute.jumped) instead of always creating a new one. Adds a Foundry test exercising recurring dispute-kit and court jumps across multiple rounds and appeal flows. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Core as KlerosCore
participant DK as DisputeKitClassicBase
participant Map as Mappings
Core->>DK: createDispute(_coreDisputeID, _numberOfChoices, _extraData)
DK->>Map: coreDisputeIDToActive[_coreDisputeID]?
alt Active dispute exists
DK->>Map: localID = coreDisputeIDToLocal[_coreDisputeID]
DK->>DK: load dispute(localID)
DK->>DK: dispute.jumped = false
DK-->>Core: return localID
else No active dispute
DK->>DK: create new local dispute (init numberOfChoices, extraData)
DK->>Map: coreDisputeIDToLocal[_coreDisputeID] = newID
DK->>Map: coreDisputeIDToActive[_coreDisputeID] = true
DK-->>Core: return newID
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related issues
Possibly related PRs
Suggested labels
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 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 |
✅ Deploy Preview for kleros-v2-testnet ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for kleros-v2-neo ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
contracts/test/foundry/KlerosCore_Appeals.t.sol (4)
609-619: Pin event emitters to avoid false positivesTie expected logs to their emitters to ensure they come from the intended contracts.
Apply this diff:
- vm.expectEmit(true, true, true, true); + vm.expectEmit(address(core)); emit KlerosCore.CourtJump(disputeID, 1, courtID3, courtID2); - vm.expectEmit(true, true, true, true); + vm.expectEmit(address(core)); emit KlerosCore.DisputeKitJump(disputeID, 1, dkID3, dkID2); - vm.expectEmit(true, true, true, true); + vm.expectEmit(address(disputeKit2)); emit DisputeKitClassicBase.DisputeCreation(disputeID, 2, newExtraData); - vm.expectEmit(true, true, true, true); + vm.expectEmit(address(core)); emit KlerosCore.AppealDecision(disputeID, arbitrable); - vm.expectEmit(true, true, true, true); + vm.expectEmit(address(core)); emit KlerosCore.NewPeriod(disputeID, KlerosCore.Period.evidence);
685-691: Also pin emitters on the second jump (and consider asserting NewPeriod)Use specific emitters here as well; optionally assert NewPeriod(evidence) like in the first jump.
- vm.expectEmit(true, true, true, true); + vm.expectEmit(address(core)); emit KlerosCore.CourtJump(disputeID, 2, courtID2, GENERAL_COURT); - vm.expectEmit(true, true, true, true); + vm.expectEmit(address(core)); emit KlerosCore.DisputeKitJump(disputeID, 2, dkID2, dkID3); + vm.expectEmit(address(core)); + emit KlerosCore.NewPeriod(disputeID, KlerosCore.Period.evidence);
605-606: Avoid magic funding amounts; compute from appealCost and multipliersHard-coded values (0.63, 0.42, 1.35, 0.9 ether) will drift if fees/multipliers change. Derive from core.appealCost(disputeID).
Example:
- disputeKit3.fundAppeal{value: 0.63 ether}(disputeID, 1); + uint256 ac1 = core.appealCost(disputeID); + uint256 lose1 = ac1 + (ac1 * 20000) / Constants.MULTIPLIER_DIVISOR; + disputeKit3.fundAppeal{value: lose1}(disputeID, 1); ... - disputeKit3.fundAppeal{value: 0.42 ether}(disputeID, 2); + uint256 win1 = ac1 + (ac1 * 10000) / Constants.MULTIPLIER_DIVISOR; + disputeKit3.fundAppeal{value: win1}(disputeID, 2); ... - disputeKit2.fundAppeal{value: 1.35 ether}(disputeID, 1); + uint256 ac2 = core.appealCost(disputeID); + uint256 lose2 = ac2 + (ac2 * 20000) / Constants.MULTIPLIER_DIVISOR; + disputeKit2.fundAppeal{value: lose2}(disputeID, 1); ... - disputeKit2.fundAppeal{value: 0.9 ether}(disputeID, 2); + uint256 win2 = ac2 + (ac2 * 10000) / Constants.MULTIPLIER_DIVISOR; + disputeKit2.fundAppeal{value: win2}(disputeID, 2);Note: If multipliers are accessible via getters, prefer them over literals.
Also applies to: 620-621, 683-684, 690-691
758-766: Optional: assert total rounds after the second jumpQuick sanity on core-side tracking.
core.executeRuling(disputeID); // winning choice is 2 + assertEq(core.getNumberOfRounds(disputeID), 3, "Should have 3 rounds after two appeals");
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
contracts/test/foundry/KlerosCore_Appeals.t.sol(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (14)
- GitHub Check: Redirect rules - kleros-v2-testnet
- GitHub Check: Redirect rules - kleros-v2-testnet-devtools
- GitHub Check: Redirect rules - kleros-v2-testnet
- GitHub Check: Header rules - kleros-v2-testnet-devtools
- GitHub Check: Header rules - kleros-v2-testnet
- GitHub Check: Redirect rules - kleros-v2-neo
- GitHub Check: Header rules - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-testnet-devtools
- GitHub Check: Header rules - kleros-v2-neo
- GitHub Check: Pages changed - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-neo
- GitHub Check: Analyze (javascript)
- GitHub Check: hardhat-tests
🔇 Additional comments (1)
contracts/test/foundry/KlerosCore_Appeals.t.sol (1)
470-793: Thorough recurring DK/court jump scenario — looks solidCovers re-entry semantics, round mapping, jump gating, events, and withdrawals end-to-end. No blockers.
2 participants
PR-Codex overview
This PR focuses on enhancing the dispute handling in the
DisputeKitClassicBasecontract, specifically addressing scenarios where disputes jump between different dispute kits. It includes new logic for managing local dispute IDs and supports testing for recurring dispute kit appeals.Detailed summary
Disputestructure initialization based on dispute kit jumps.test_appeal_recurringDKto validate dispute kit jumping behavior.Summary by CodeRabbit
Bug Fixes
Tests