feat(escrow): emit structured disputed event#276
Conversation
|
@codewithzubair07 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthrough
ChangesEscrow Dispute Event Enrichment
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Tools execution failed with the following error: Failed to run tools: 13 INTERNAL: Received RST_STREAM with code 2 (Internal server error) Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
contracts/escrow/src/integration_tests.rs (1)
224-228: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd assertions for the dispute event and terminal-state rejection.
- Check the emitted
EscrowDisputedEventfields/count (escrow_idshould matcht.order_id(), plusraised_by,reason_code, andledger).- Add a negative case for
disputeafterReleased/Refundedescrows (InvalidStatus).🤖 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 `@contracts/escrow/src/integration_tests.rs` around lines 224 - 228, The current `escrow_client.dispute` test only checks the call succeeds, so extend this case to assert the emitted `EscrowDisputedEvent` and its count, verifying `escrow_id` matches `t.order_id()` and that `raised_by`, `reason_code`, and `ledger` are correct. Also add a negative assertion in the integration test flow for calling `dispute` on terminal escrows after `Released` or `Refunded`, and confirm it returns `InvalidStatus` by exercising the same `escrow_client.dispute` path used in the existing test.
🤖 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 `@contracts/escrow/src/integration_tests.rs`:
- Around line 224-228: The current `escrow_client.dispute` test only checks the
call succeeds, so extend this case to assert the emitted `EscrowDisputedEvent`
and its count, verifying `escrow_id` matches `t.order_id()` and that
`raised_by`, `reason_code`, and `ledger` are correct. Also add a negative
assertion in the integration test flow for calling `dispute` on terminal escrows
after `Released` or `Refunded`, and confirm it returns `InvalidStatus` by
exercising the same `escrow_client.dispute` path used in the existing test.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 30c95903-ae9e-437e-9bb9-8354ec28c5f7
📒 Files selected for processing (2)
contracts/escrow/src/integration_tests.rscontracts/escrow/src/lib.rs
|
Fix the ci |
|
Please resolve conflicts |
Summary
This PR implements structured dispute event emission for the escrow contract.
Changes
EscrowDisputedEvent.raised_by,reason_code, andledgerin the event payload.order_idas the eventescrow_id(BytesN<32>), matching the required event shape while keeping the change scoped to the escrow contract.disputefunction to accept areason_code.Closes #89
Summary by CodeRabbit
New Features
Bug Fixes
Tests