chore: sync ChainvoiceABI with deployed hash-based contract - #193
Conversation
|
Warning Review limit reached
Next review available in: 59 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
WalkthroughThe frontend ABI now uses ChangesContract alignment
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: Poem
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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.
Inline comments:
In `@frontend/.env.example`:
- Around line 4-8: Update the Sepolia contract address references in README.md
and frontend/README.md to match VITE_CONTRACT_ADDRESS_11155111 in
frontend/.env.example, replacing the old address unless it is intentionally the
primary address. Ensure both documentation files consistently describe the
current frontend configuration and deployed contract address.
In `@frontend/src/contractsABI/ChainvoiceABI.js`:
- Around line 80-82: Synchronize the invoice callers with the updated ABI:
update CreateInvoice’s createInvoice invocation to four arguments with a
non-empty bytes32, change CreateInvoicesBatch to pass one bytes32[] instead of
payload and hash arrays, and revise ReceivedInvoice and SentInvoice to read the
migrated tuple’s new off-chain fields without relying on invoice[7]/invoice[8].
Ensure migrated invoices remain included and all computed hash values are valid
bytes32 values.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 38240a44-b534-40d7-b854-c27c0c748cee
📒 Files selected for processing (2)
frontend/.env.examplefrontend/src/contractsABI/ChainvoiceABI.js
be9e09d to
f67063e
Compare
The frontend ABI still described the pre-migration contract, which stored the full invoice payload on-chain as two strings: createInvoice(address, uint256, address, string, string) contracts/src/Chainvoice.sol has since moved to storing only a keccak256 commitment of the invoice data, and gained the public key registry: createInvoice(address, uint256, address, bytes32) Regenerated from `forge build` output so the ABI matches the contract source exactly. This also drops the `wakuPublicKeys` accessor, which is now a private mapping read through `getWakuPublicKey`. .env.example pointed at 0x54a5…, the old contract, where getWakuPublicKey reverts and getInvoice returns strings — following the setup docs would have produced an ABI/contract mismatch. Repointed at the Sepolia deployment of the current source. Ethereum Classic and Polygon still run the old contract and are flagged inline as needing redeployment. Callers in the invoice pages still pass the old string arguments and are updated separately; this commit only realigns the ABI with the contract.
f67063e to
d409cc6
Compare
3 participants
Addressed Issues:
Part of #139 (1 of 5). Does not close it on its own.
Screenshots/Recordings:
Not applicable — no user-visible change. This PR only realigns the ABI with the contract source.
Additional Notes:
The frontend ABI still described the pre-migration contract, which stored the full invoice payload on-chain as two strings:
contracts/src/Chainvoice.solhas since moved to storing only a keccak256 commitment of the invoice data, and gained the public key registry:Regenerated from
forge buildoutput so the ABI matches the contract source exactly. This also drops thewakuPublicKeysaccessor, which is now a private mapping read throughgetWakuPublicKey..env.examplepointed at0x54a5…, the old contract, wheregetWakuPublicKeyreverts andgetInvoicereturns strings — following the setup docs would have produced an ABI/contract mismatch. Ethereum Classic and Polygon still run the old contract and are flagged inline as needing redeployment.Why it is separate: this is a mechanical regeneration with no behaviour of its own. Splitting it out keeps the transport migration reviewable without an 850-line ABI diff in the middle of it.
Review order: must land together with #195 — on its own it leaves callers passing the old string arguments to a 4-argument function. Order: this → #194 → #195.
AI Usage Disclosure:
Check one of the checkboxes below:
I have used the following AI models and tools: Claude Code (CLI), model Claude Opus 5
Checklist
Summary by CodeRabbit
New Features
Bug Fixes