feat: implement ERC20CommerceEscrowWrapper with event handling and schema updates #112
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughAdds ERC20CommerceEscrowWrapper support: new contract ABI, subgraph datasources for Base/Sepolia, GraphQL schema/entities for commerce escrows/events, mapping handlers to track escrow lifecycle, shared utilities for IDs/events, and manifest/CLI updates including artifact registration and ignored events. Changes
Sequence Diagram(s)sequenceDiagram
participant Client as Client (payer/merchant)
participant Contract as ERC20CommerceEscrowWrapper
participant Indexer as Subgraph Mapping
participant Store as Graph Store
Client->>Contract: call authorize/charge/capture/void/refund/reclaim
Contract-->>Contract: emit event (PaymentAuthorized/Charged/Captured/Voided/Refunded/Reclaimed)
Contract->>Indexer: node delivers on-chain event
Indexer->>Indexer: parse event, derive paymentReference
Indexer->>Store: load/create CommerceEscrow entity
Indexer->>Store: update CommerceEscrow state
Indexer->>Store: create CommerceEscrowEvent (include amount if present)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used📓 Path-based instructions (1)**/*⚙️ CodeRabbit configuration file
Files:
🧠 Learnings (1)📚 Learning: 2024-11-11T15:47:43.409ZApplied to files:
🔇 Additional comments (1)
Comment |
Contributor
Greptile OverviewGreptile SummaryAdds support for tracking ERC20 commerce escrow payments through a new subgraph datasource. The implementation introduces Key changes:
Issues found:
Confidence Score: 3/5
Important Files ChangedFile Analysis
Sequence DiagramsequenceDiagram
participant User as Payer/Merchant
participant Contract as ERC20CommerceEscrowWrapper
participant Subgraph as Subgraph Indexer
participant Graph as The Graph
Note over User,Graph: Payment Authorization Flow
User->>Contract: authorizePayment()
Contract->>Contract: Emit PaymentAuthorized
Contract-->>Subgraph: PaymentAuthorized event
Subgraph->>Graph: Create CommerceEscrow entity
Subgraph->>Graph: Create CommerceEscrowEvent (authorized)
Note over User,Graph: Payment Capture Flow
User->>Contract: capturePayment()
Contract->>Contract: Emit PaymentCaptured
Contract-->>Subgraph: PaymentCaptured event
Subgraph->>Graph: Update escrowState to "captured"
Subgraph->>Graph: Create CommerceEscrowEvent (captured)
Note over User,Graph: Payment Void Flow
User->>Contract: voidPayment()
Contract->>Contract: Emit PaymentVoided
Contract-->>Subgraph: PaymentVoided event
Subgraph->>Graph: Update escrowState to "voided"
Subgraph->>Graph: Create CommerceEscrowEvent (voided)
Note over User,Graph: Direct Charge Flow (No Prior Authorization)
User->>Contract: chargePayment()
Contract->>Contract: Emit PaymentCharged
Contract-->>Subgraph: PaymentCharged event
Subgraph->>Graph: Create CommerceEscrow entity
Subgraph->>Graph: Create CommerceEscrowEvent (charged)
Note over User,Graph: Payment Reclaim Flow
User->>Contract: reclaimPayment()
Contract->>Contract: Emit PaymentReclaimed
Contract-->>Subgraph: PaymentReclaimed event
Subgraph->>Graph: Update escrowState to "reclaimed"
Subgraph->>Graph: Create CommerceEscrowEvent (reclaimed)
Note over User,Graph: Payment Refund Flow
User->>Contract: refundPayment()
Contract->>Contract: Emit PaymentRefunded
Contract-->>Subgraph: PaymentRefunded event
Subgraph->>Graph: Update escrowState to "refunded"
Subgraph->>Graph: Create CommerceEscrowEvent (refunded)
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (7)
abis/ERC20CommerceEscrowWrapper.json(1 hunks)cli/lib/manifest.ts(6 hunks)package.json(1 hunks)schema.graphql(1 hunks)src/erc20CommerceEscrowWrapper.ts(1 hunks)src/shared.ts(2 hunks)subgraph.sepolia.yaml(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*
⚙️ CodeRabbit configuration file
**/*: - Only comment on issues that would block merging — ignore minor or stylistic concerns.
- Restrict feedback to errors, security risks, or functionality-breaking problems.
- Do not post comments on code style, formatting, or non-critical improvements.
- Keep reviews short: flag only issues that make the PR unsafe to merge.
- Limit review comments to 3–5 items maximum, unless additional blockers exist.
- Group similar issues into a single comment instead of posting multiple notes.
- Skip repetition — if a pattern repeats, mention it once at a summary level only.
- Do not add general suggestions; focus strictly on merge-blocking concerns.
- If there are no critical problems, respond with minimal approval (e.g., 'Looks good'). Do not add additional review.
- Avoid line-by-line commentary unless it highlights a critical bug or security hole.
- Highlight only issues that could cause runtime errors, data loss, or severe maintainability issues.
- Ignore minor optimization opportunities — focus solely on correctness and safety.
- Provide a top-level summary of critical blockers rather than detailed per-line notes.
- Comment only when the issue must be resolved before merge — otherwise, remain silent.
- When in doubt, err on the side of fewer comments — brevity and blocking issues only.
- Avoid posting any refactoring issues
Files:
subgraph.sepolia.yamlpackage.jsonsrc/erc20CommerceEscrowWrapper.tssrc/shared.tsschema.graphqlcli/lib/manifest.tsabis/ERC20CommerceEscrowWrapper.json
🧠 Learnings (8)
📓 Common learnings
Learnt from: MantisClone
Repo: RequestNetwork/payments-subgraph PR: 104
File: abis/SingleRequestProxyFactory.json:23-123
Timestamp: 2024-11-05T04:48:47.738Z
Learning: In the 'payments-subgraph' project, when changing smart contracts is not within the scope of a PR, avoid commenting on ABI files suggesting changes to the smart contracts.
Learnt from: MantisClone
Repo: RequestNetwork/payments-subgraph PR: 104
File: src/singleRequestProxyFactory.ts:1-38
Timestamp: 2024-11-05T04:48:44.308Z
Learning: In the `payments-subgraph` project, within `src/singleRequestProxyFactory.ts`, it is acceptable to assume that event handling functions do not require additional error handling or failed transaction handling, as errors in event handling are uncommon in this context.
📚 Learning: 2024-11-05T04:48:47.738Z
Learnt from: MantisClone
Repo: RequestNetwork/payments-subgraph PR: 104
File: abis/SingleRequestProxyFactory.json:23-123
Timestamp: 2024-11-05T04:48:47.738Z
Learning: In the 'payments-subgraph' project, when changing smart contracts is not within the scope of a PR, avoid commenting on ABI files suggesting changes to the smart contracts.
Applied to files:
subgraph.sepolia.yamlpackage.jsonabis/ERC20CommerceEscrowWrapper.json
📚 Learning: 2024-11-11T15:47:45.143Z
Learnt from: MantisClone
Repo: RequestNetwork/payments-subgraph PR: 107
File: subgraph.bsc.yaml:156-179
Timestamp: 2024-11-11T15:47:45.143Z
Learning: For the event handlers `handleERC20SingleRequestProxyCreated` and `handleEthereumSingleRequestProxyCreated` in `src/singleRequestProxyFactory.ts`, duplicates are acceptable, and event replay protection is not required.
Applied to files:
subgraph.sepolia.yamlsrc/erc20CommerceEscrowWrapper.tscli/lib/manifest.ts
📚 Learning: 2024-11-05T04:48:44.308Z
Learnt from: MantisClone
Repo: RequestNetwork/payments-subgraph PR: 104
File: src/singleRequestProxyFactory.ts:1-38
Timestamp: 2024-11-05T04:48:44.308Z
Learning: In the `payments-subgraph` project, within `src/singleRequestProxyFactory.ts`, it is acceptable to assume that event handling functions do not require additional error handling or failed transaction handling, as errors in event handling are uncommon in this context.
Applied to files:
subgraph.sepolia.yamlsrc/erc20CommerceEscrowWrapper.tscli/lib/manifest.ts
📚 Learning: 2024-11-11T15:47:40.531Z
Learnt from: MantisClone
Repo: RequestNetwork/payments-subgraph PR: 107
File: subgraph.mantle.yaml:89-95
Timestamp: 2024-11-11T15:47:40.531Z
Learning: In the Mantle configuration file `subgraph.mantle.yaml`, the start block for the `SingleRequestProxyFactory` contract is `71485828`, and this is correct even though it is significantly higher than other start blocks in the same network.
Applied to files:
subgraph.sepolia.yaml
📚 Learning: 2024-11-11T15:47:43.409Z
Learnt from: MantisClone
Repo: RequestNetwork/payments-subgraph PR: 107
File: src/singleRequestProxyFactory.ts:30-30
Timestamp: 2024-11-11T15:47:43.409Z
Learning: In `src/singleRequestProxyFactory.ts` (TypeScript), when constructing unique identifiers by concatenating strings (e.g., transaction hash and log index), prefer using string concatenation with `+` instead of template literals.
Applied to files:
src/shared.ts
📚 Learning: 2024-11-05T04:48:58.313Z
Learnt from: MantisClone
Repo: RequestNetwork/payments-subgraph PR: 104
File: schema.graphql:72-82
Timestamp: 2024-11-05T04:48:58.313Z
Learning: In the `schema.graphql` file of the `payments-subgraph` project, we should not add a `created_at` field to entities when a `timestamp` field is already present, as `timestamp` provides precise chronological ordering.
Applied to files:
schema.graphql
📚 Learning: 2024-11-05T04:48:58.313Z
Learnt from: MantisClone
Repo: RequestNetwork/payments-subgraph PR: 104
File: schema.graphql:72-82
Timestamp: 2024-11-05T04:48:58.313Z
Learning: In the payments-subgraph, it's unnecessary to include a `network` field in entities because each subgraph is chain-specific.
Applied to files:
cli/lib/manifest.ts
🧬 Code graph analysis (1)
src/erc20CommerceEscrowWrapper.ts (1)
src/shared.ts (2)
generateCommerceEscrowId(45-47)createCommerceEscrowEvent(58-79)
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/erc20CommerceEscrowWrapper.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*
⚙️ CodeRabbit configuration file
**/*: - Only comment on issues that would block merging — ignore minor or stylistic concerns.
- Restrict feedback to errors, security risks, or functionality-breaking problems.
- Do not post comments on code style, formatting, or non-critical improvements.
- Keep reviews short: flag only issues that make the PR unsafe to merge.
- Limit review comments to 3–5 items maximum, unless additional blockers exist.
- Group similar issues into a single comment instead of posting multiple notes.
- Skip repetition — if a pattern repeats, mention it once at a summary level only.
- Do not add general suggestions; focus strictly on merge-blocking concerns.
- If there are no critical problems, respond with minimal approval (e.g., 'Looks good'). Do not add additional review.
- Avoid line-by-line commentary unless it highlights a critical bug or security hole.
- Highlight only issues that could cause runtime errors, data loss, or severe maintainability issues.
- Ignore minor optimization opportunities — focus solely on correctness and safety.
- Provide a top-level summary of critical blockers rather than detailed per-line notes.
- Comment only when the issue must be resolved before merge — otherwise, remain silent.
- When in doubt, err on the side of fewer comments — brevity and blocking issues only.
- Avoid posting any refactoring issues
Files:
src/erc20CommerceEscrowWrapper.ts
🧠 Learnings (2)
📚 Learning: 2024-11-05T04:48:44.308Z
Learnt from: MantisClone
Repo: RequestNetwork/payments-subgraph PR: 104
File: src/singleRequestProxyFactory.ts:1-38
Timestamp: 2024-11-05T04:48:44.308Z
Learning: In the `payments-subgraph` project, within `src/singleRequestProxyFactory.ts`, it is acceptable to assume that event handling functions do not require additional error handling or failed transaction handling, as errors in event handling are uncommon in this context.
Applied to files:
src/erc20CommerceEscrowWrapper.ts
📚 Learning: 2024-11-11T15:47:45.143Z
Learnt from: MantisClone
Repo: RequestNetwork/payments-subgraph PR: 107
File: subgraph.bsc.yaml:156-179
Timestamp: 2024-11-11T15:47:45.143Z
Learning: For the event handlers `handleERC20SingleRequestProxyCreated` and `handleEthereumSingleRequestProxyCreated` in `src/singleRequestProxyFactory.ts`, duplicates are acceptable, and event replay protection is not required.
Applied to files:
src/erc20CommerceEscrowWrapper.ts
🧬 Code graph analysis (1)
src/erc20CommerceEscrowWrapper.ts (1)
src/shared.ts (2)
generateCommerceEscrowId(45-47)createCommerceEscrowEvent(58-79)
🪛 Biome (2.1.2)
src/erc20CommerceEscrowWrapper.ts
[error] 107-107: Shouldn't redeclare 'escrow'. Consider to delete it or rename it.
'escrow' is defined here:
(lint/suspicious/noRedeclare)
…dd ERC20CommerceEscrowWrapper data source to subgraph configurations
…TF8 for ID generation
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/shared.ts(2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*
⚙️ CodeRabbit configuration file
**/*: - Only comment on issues that would block merging — ignore minor or stylistic concerns.
- Restrict feedback to errors, security risks, or functionality-breaking problems.
- Do not post comments on code style, formatting, or non-critical improvements.
- Keep reviews short: flag only issues that make the PR unsafe to merge.
- Limit review comments to 3–5 items maximum, unless additional blockers exist.
- Group similar issues into a single comment instead of posting multiple notes.
- Skip repetition — if a pattern repeats, mention it once at a summary level only.
- Do not add general suggestions; focus strictly on merge-blocking concerns.
- If there are no critical problems, respond with minimal approval (e.g., 'Looks good'). Do not add additional review.
- Avoid line-by-line commentary unless it highlights a critical bug or security hole.
- Highlight only issues that could cause runtime errors, data loss, or severe maintainability issues.
- Ignore minor optimization opportunities — focus solely on correctness and safety.
- Provide a top-level summary of critical blockers rather than detailed per-line notes.
- Comment only when the issue must be resolved before merge — otherwise, remain silent.
- When in doubt, err on the side of fewer comments — brevity and blocking issues only.
- Avoid posting any refactoring issues
Files:
src/shared.ts
🧠 Learnings (1)
📚 Learning: 2024-11-11T15:47:43.409Z
Learnt from: MantisClone
Repo: RequestNetwork/payments-subgraph PR: 107
File: src/singleRequestProxyFactory.ts:30-30
Timestamp: 2024-11-11T15:47:43.409Z
Learning: In `src/singleRequestProxyFactory.ts` (TypeScript), when constructing unique identifiers by concatenating strings (e.g., transaction hash and log index), prefer using string concatenation with `+` instead of template literals.
Applied to files:
src/shared.ts
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
aimensahnoun
approved these changes
Dec 16, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Changes
Sample
Summary by CodeRabbit
New Features
Chores
✏️ Tip: You can customize this high-level summary in your review settings.