feat(user-ops-indexer): support entrypoint v08 #1296
Conversation
WalkthroughThis pull request introduces support for multiple entry points across User Ops Indexer versions. The README now indicates that contract addresses for entry points are comma separated, allowing for multiple inputs per version. In the codebase, single entry point fields and methods have been replaced with vectors, and new methods to match entry points have been added. The Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
⏰ Context from checks skipped due to timeout of 90000ms (1)
🔇 Additional comments (1)
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Pull Request Overview
This PR introduces support for entrypoint v08 by updating proto definitions, migration scripts, and indexer logic to handle multiple entry points. Key changes include:
- Updating proto messages and field names (renaming v07 to v07_v08) and deprecating raw user op messages.
- Adding a new migration (m20250326_080441_entrypoint_v08.rs) to update the entrypoint type.
- Refactoring indexer logic and settings to support vectors of entrypoint addresses for v06, v07, and v08.
Reviewed Changes
Copilot reviewed 22 out of 25 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| user-ops-indexer-proto/proto/user-ops-indexer.proto | Renamed field and updated proto definitions to support entrypoint v08. |
| user-ops-indexer-proto/build.rs | Added extern path for google.protobuf types. |
| user-ops-indexer-proto/Cargo.toml | Included prost-wkt dependencies. |
| user-ops-indexer-migration | Added migration script for v08 and updated migrator. |
| user-ops-indexer-logic/src/types/user_op.rs | Updated raw user op conversion to use JSON instead of oneof. |
| user-ops-indexer-logic (v07, v06, base_indexer, settings, status, rpc_utils, tests) | Refactored indexer logic for multi-entrypoint support and updated tests accordingly. |
| user-ops-indexer/README.md | Updated environment variable documentation to include v08 settings. |
Files not reviewed (3)
- user-ops-indexer/user-ops-indexer-logic/src/indexer/tests/fixtures/handle_tx_v06_ok.json: Language not supported
- user-ops-indexer/user-ops-indexer-logic/src/indexer/tests/fixtures/handle_tx_v07_ok.json: Language not supported
- user-ops-indexer/user-ops-indexer-logic/src/indexer/tests/fixtures/handle_tx_v08_ok.json: Language not supported
Comments suppressed due to low confidence (1)
user-ops-indexer/user-ops-indexer-proto/proto/user-ops-indexer.proto:127
- [nitpick] The field name 'v07_v08' could be ambiguous; consider renaming it to more explicitly reflect its purpose (e.g., 'v07_and_v08') or provide additional documentation to clarify its meaning.
EntryPointIndexerStatus v07_v08 = 3;
![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
♻️ Duplicate comments (1)
user-ops-indexer/user-ops-indexer-logic/src/types/user_op.rs (1)
214-214:⚠️ Potential issueImprove error handling in JSON deserialization
Using
.expect()for deserialization could cause a runtime panic if deserialization fails. Consider propagating the error or handling it gracefully to improve robustness.- raw: serde_json::from_value(raw).expect("deserialize raw failed"), + raw: match serde_json::from_value(raw) { + Ok(value) => value, + Err(e) => { + eprintln!("Failed to deserialize raw: {}", e); + return Err(e.into()); + } + },
🧹 Nitpick comments (13)
user-ops-indexer/user-ops-indexer-migration/src/m20250326_080441_entrypoint_v08.rs (1)
15-17: Consider implementing a rollback strategy.Leaving
downempty means there is no way to remove the'v0.8'value if you need to revert. If rollback is important, consider removing'v0.8'from the type in thedownmethod or adding a comment explaining why no rollback is required.user-ops-indexer/user-ops-indexer-logic/src/indexer/rpc_utils.rs (1)
201-219: Inheriting reverted status withmark_reverted_parents.This function ensures that if an ancestor trace has a non-empty error, all descendants also become reverted. The approach of tracking the earliest revert level is succinct. Confirm in tests that multi-level nesting and partial reverts produce the expected outcome.
Consider extended test coverage for multiple revert paths to ensure correctness of overshadowed or nested reverts.
user-ops-indexer/user-ops-indexer-server/src/indexer.rs (2)
69-69: Warning log message
The warning looks good for indicating that both v0.7 and v0.8 are off. If you frequently check logs to troubleshoot, consider whether tracing at “info” level is more appropriate.
83-83: Log statement includes entry points
Logginglogic.entry_points()is informative. If the vector of entry points is large, you could consider using a debug/trace level to avoid verbose logs in production.user-ops-indexer/user-ops-indexer-logic/src/indexer/v06/mod.rs (2)
43-45: Cloned vector of entry points
Returning a cloned vector is fine for read-only usage. If performance or duplication becomes a concern for large lists, consider returning a slice or reference.
47-49: Membership check
Usingcontainson aVecis correct for small vectors. If the list grows significantly, aHashSetmight improve performance.user-ops-indexer/user-ops-indexer-logic/src/indexer/v07/mod.rs (3)
45-51: Combining entry points
Joiningv07_entry_pointsandv08_entry_pointsinto a single vector is straightforward. If you anticipate duplicates across both sets, consider deduplication or using a set structure.
53-55: Simplified membership check
matches_entry_pointmerges checks for v0.7 and v0.8. Same note on using aHashSetfor large datasets.
236-241: Determine entry point version
Switching betweenV08orV07based on membership inv08_entry_pointsorv07_entry_pointsis correct. Consider an error case if the address is in neither.user-ops-indexer/user-ops-indexer-logic/src/indexer/base_indexer.rs (4)
90-95: Refactor return type for consistency.Although returning
Option<sol_types::Result<T>>works, consider using a singleanyhow::Result<Option<T>>or similar to provide clearer error propagation and uniformity.-fn match_and_parse<T: SolEvent>(&self, entry_point: Address, log: &Log) -> Option<sol_types::Result<T>> { - if log.address() == entry_point && log.topic0() == Some(&T::SIGNATURE_HASH) { - Some(T::decode_log(&log.inner, true).map(|l| l.data)) - } else { - None - } +fn match_and_parse<T: SolEvent>(&self, entry_point: Address, log: &Log) -> anyhow::Result<Option<T>> { + if log.address() == entry_point && log.topic0() == Some(&T::SIGNATURE_HASH) { + T::decode_log(&log.inner, true) + .map(|l| Some(l.data)) + .map_err(|e| anyhow::anyhow!(e)) + } else { + Ok(None) + } }
193-217: Potential performance consideration for many entry points.Looping over all entry points with separate queries can be expensive if the list is large. Consider batching or parallelizing these calls to improve performance.
423-427: Graceful error handling for user ops parsing.Combining
zipwith the bundling logic is concise. To further aid debugging, consider logging each parse failure more verbosely in themap_errbranch.
700-767: Extensive v08 testing.This test confirms the new variant’s correctness, verifying each field in
UserOp. For completeness, consider an additional test covering multiple v08 entry points in one transaction to ensure multi-address functionality fully works.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
user-ops-indexer/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (24)
user-ops-indexer/README.md(1 hunks)user-ops-indexer/user-ops-indexer-entity/src/sea_orm_active_enums.rs(1 hunks)user-ops-indexer/user-ops-indexer-logic/Cargo.toml(1 hunks)user-ops-indexer/user-ops-indexer-logic/src/indexer/base_indexer.rs(11 hunks)user-ops-indexer/user-ops-indexer-logic/src/indexer/common.rs(1 hunks)user-ops-indexer/user-ops-indexer-logic/src/indexer/rpc_utils.rs(5 hunks)user-ops-indexer/user-ops-indexer-logic/src/indexer/settings.rs(3 hunks)user-ops-indexer/user-ops-indexer-logic/src/indexer/status.rs(3 hunks)user-ops-indexer/user-ops-indexer-logic/src/indexer/tests/fixtures/handle_tx_v06_ok.json(1 hunks)user-ops-indexer/user-ops-indexer-logic/src/indexer/tests/fixtures/handle_tx_v06_with_tracing_ok.json(1 hunks)user-ops-indexer/user-ops-indexer-logic/src/indexer/tests/fixtures/handle_tx_v07_ok.json(1 hunks)user-ops-indexer/user-ops-indexer-logic/src/indexer/tests/fixtures/handle_tx_v08_ok.json(1 hunks)user-ops-indexer/user-ops-indexer-logic/src/indexer/v06/mod.rs(9 hunks)user-ops-indexer/user-ops-indexer-logic/src/indexer/v07/mod.rs(9 hunks)user-ops-indexer/user-ops-indexer-logic/src/repository/user_op.rs(1 hunks)user-ops-indexer/user-ops-indexer-logic/src/types/user_op.rs(3 hunks)user-ops-indexer/user-ops-indexer-migration/src/lib.rs(2 hunks)user-ops-indexer/user-ops-indexer-migration/src/m20250326_080441_entrypoint_v08.rs(1 hunks)user-ops-indexer/user-ops-indexer-proto/Cargo.toml(1 hunks)user-ops-indexer/user-ops-indexer-proto/build.rs(1 hunks)user-ops-indexer/user-ops-indexer-proto/proto/user-ops-indexer.proto(3 hunks)user-ops-indexer/user-ops-indexer-proto/swagger/user-ops-indexer.swagger.yaml(3 hunks)user-ops-indexer/user-ops-indexer-server/Cargo.toml(1 hunks)user-ops-indexer/user-ops-indexer-server/src/indexer.rs(5 hunks)
🧰 Additional context used
🧬 Code Definitions (3)
user-ops-indexer/user-ops-indexer-migration/src/m20250326_080441_entrypoint_v08.rs (1)
user-ops-indexer/user-ops-indexer-migration/src/lib.rs (1)
from_sql(27-39)
user-ops-indexer/user-ops-indexer-logic/src/indexer/v07/mod.rs (2)
user-ops-indexer/user-ops-indexer-logic/src/indexer/v06/mod.rs (2)
entry_points(43-45)matches_entry_point(47-49)user-ops-indexer/user-ops-indexer-logic/src/indexer/common.rs (2)
extract_address(34-40)extract_user_logs_boundaries(57-75)
user-ops-indexer/user-ops-indexer-logic/src/indexer/base_indexer.rs (2)
user-ops-indexer/user-ops-indexer-logic/src/indexer/v07/mod.rs (5)
entry_points(45-51)matches_entry_point(53-55)matches_handler_calldata(57-60)parse_user_ops(62-155)user_ops(125-154)user-ops-indexer/user-ops-indexer-logic/src/indexer/v06/mod.rs (5)
entry_points(43-45)matches_entry_point(47-49)matches_handler_calldata(51-54)parse_user_ops(56-149)user_ops(119-148)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Docker build and docker push / build-and-push
🔇 Additional comments (71)
user-ops-indexer/user-ops-indexer-server/Cargo.toml (1)
22-22:❓ Verification inconclusive
Significant version upgrade for alloy dependency.
The alloy dependency has been updated from version 0.9.2 to 0.13.0, which is a substantial version jump. While the requested features remain the same, this update may introduce breaking changes in the alloy API.
Please verify that all usages of the alloy library are compatible with the new version by running the following commands:
🏁 Script executed:
#!/bin/bash # Check for any breaking changes in the alloy API usage rg -t rust "::alloy::|use alloy" --include "*.rs"Length of output: 493
Verify Alloy API Compatibility – Manual Verification Required
The alloy dependency was upgraded from version 0.9.2 to 0.13.0, which is a significant jump and may introduce breaking changes in the alloy API. The originally suggested verification command failed due to an invalid
--includeflag. To ensure that all alloy API usages are compatible with the new version, please re-run the check with the following corrected command:#!/bin/bash # Re-run the alloy usage search without the invalid --include option rg -t rust '(::alloy::|use alloy)'After executing the above command, please manually verify that there are no API usage changes or incompatibilities in your Rust codebase. Adjust the code as necessary if any breaking changes are identified.
user-ops-indexer/user-ops-indexer-proto/Cargo.toml (1)
11-12: New protobuf dependencies added for well-known types support.The addition of
prost-wktandprost-wkt-typesdependencies aligns with the changes in the proto file wheregoogle.protobuf.Structis now used. These dependencies provide support for Protocol Buffer well-known types.user-ops-indexer/user-ops-indexer-proto/proto/user-ops-indexer.proto (3)
127-127: Field renamed to accommodate multiple entry point versions.The field has been renamed from
v07tov07_v08, indicating that the same status structure will be used for both v0.7 and v0.8 entry points. This is a good approach for consolidating status management.
182-182: Simplified UserOp raw field using well-known type.The
rawfield has been changed from a specific oneof to a more genericgoogle.protobuf.Structtype. This simplifies the message structure and provides more flexibility for handling different versions of user operations.
208-209:❓ Verification inconclusive
Updated field indices for execute_target and execute_call_data.
The field indices have been updated to 35 and 36. Ensure that any clients using these fields are updated to use the new indices.
🏁 Script executed:
#!/bin/bash # Check for any direct references to field indices in the codebase rg -t rust "execute_target.*\b3[0-4]\b|execute_call_data.*\b3[0-4]\b"Length of output: 71
Action Required: Confirm Updated Field Indices
The proto file at
user-ops-indexer/user-ops-indexer-proto/proto/user-ops-indexer.protonow reflects the updated field indices forexecute_targetandexecute_call_data(35 and 36). An initial regex check for references to indices 30–34 did not produce any matches. However, given the minimal output from the search, please perform a manual review to ensure no client code is still relying on the old indices.
- Verify that no part of the codebase references outdated indices for these fields.
- Confirm that all consuming clients have been updated to reference the new indices (35 and 36).
user-ops-indexer/user-ops-indexer-entity/src/sea_orm_active_enums.rs (1)
16-17: Added V08 variant to EntryPointVersion enum.The addition of the V08 variant is consistent with the existing pattern and supports the new entry point version. This change appropriately maps to the "v0.8" string value in the database.
Make sure that all code paths handling EntryPointVersion are updated to account for this new variant:
#!/bin/bash # Look for match expressions on EntryPointVersion that might need updating rg -t rust "match.*EntryPointVersion" -A 10user-ops-indexer/user-ops-indexer-logic/Cargo.toml (1)
32-32:❓ Verification inconclusive
Verify compatibility with the alloy version upgrade
Updating from
alloy0.9.2 to 0.13.0 is a significant version bump that might introduce breaking API changes. While keeping the same features is good, ensure all code using the alloy library has been properly adapted to the new version.
🏁 Script executed:
#!/bin/bash # Check the alloy changelog or release notes to understand breaking changes echo "Checking alloy repo for changelog between versions 0.9.2 and 0.13.0" git clone --depth 1 https://github.com/alloy-rs/alloy /tmp/alloy cd /tmp/alloy git log --oneline -- CHANGELOG.md | head -n 20Length of output: 318
Action Required: Verify Alloy Compatibility Upgrade
The alloy version bump from 0.9.2 to 0.13.0 is significant and may introduce breaking changes. Please review the alloy CHANGELOG and release notes (e.g., by browsing the alloy repository) to confirm whether any API modifications affect our usage. Then, verify that all portions of our code utilizing alloy have been updated accordingly.
- File:
user-ops-indexer/user-ops-indexer-logic/Cargo.toml(line 32)- Snippet:
alloy = { version = "0.13.0", features = ["contract", "pubsub", "provider-debug-api", "provider-trace-api"] }user-ops-indexer/user-ops-indexer-migration/src/lib.rs (1)
7-7: Migration added for entrypoint v0.8 supportThe addition of a new migration module for entrypoint v0.8 aligns well with the PR's objective to support multiple entry points. This structured approach to database schema evolution is appropriate.
Also applies to: 19-19
user-ops-indexer/user-ops-indexer-logic/src/indexer/common.rs (1)
5-5: Import style improvementConsolidating the imports from
sol_typesinto a single line improves code organization without affecting functionality.user-ops-indexer/user-ops-indexer-proto/build.rs (1)
24-25: Protocol buffer configuration for Google WKTAdding the extern path for Google protobuf types is necessary to support the updated message structures that use
google.protobuf.Structfor more flexible representation of user operations.user-ops-indexer/user-ops-indexer-logic/src/indexer/tests/fixtures/handle_tx_v08_ok.json (1)
1-141: Well-structured test fixture for v0.8 entry point support.This new fixture provides comprehensive transaction data with all necessary fields and logs for testing v0.8 entry point handling. The transaction contains detailed information including logs with various topics and events that will be useful for thorough testing of the indexer's ability to process v0.8 transactions.
user-ops-indexer/user-ops-indexer-logic/src/indexer/tests/fixtures/handle_tx_v06_with_tracing_ok.json (1)
1-686: Detailed transaction tracing fixture improves test coverage.This comprehensive fixture includes extensive transaction execution traces that will help validate internal contract calls and complex transaction flows. The level of detail enables more thorough testing of the indexer's ability to process transactions with complex execution paths.
user-ops-indexer/user-ops-indexer-logic/src/indexer/tests/fixtures/handle_tx_v07_ok.json (1)
1-246: Good addition of v0.7 transaction test fixture.This test fixture properly captures the structure of v0.7 transactions with all relevant fields and logs. It provides a solid baseline for testing v0.7 handling alongside the new v0.8 support.
user-ops-indexer/user-ops-indexer-logic/src/indexer/tests/fixtures/handle_tx_v06_ok.json (1)
1-99: Well-structured v0.6 test fixture.This fixture provides the necessary transaction data for testing v0.6 entry point handling, completing the set of test cases across supported versions.
user-ops-indexer/user-ops-indexer-logic/src/indexer/status.rs (4)
6-6: Appropriate field rename to support combined v0.7-v0.8 status tracking.Renaming the field from
v07tov07_v08aligns with the approach of handling v0.7 and v0.8 entry points together, suggesting they share similar enough behavior to use common status tracking.
33-33: Consistent update to status checking logic.Correctly updated the reference to use the renamed field in the finished_past_indexing check.
35-35: Consistent field update in protocol buffer conversion.Properly renamed the field in the conversion to the protocol buffer representation.
70-70: Updated version matcher to support combined v0.7-v0.8 status updates.The version string update from "v0.7" to "v0.7-v0.8" ensures that status messages for both v0.7 and v0.8 entry points are directed to the shared status field.
user-ops-indexer/user-ops-indexer-migration/src/m20250326_080441_entrypoint_v08.rs (2)
3-4: Migration struct naming is appropriate.Declaring a dedicated
Migrationstruct with#[derive(DeriveMigrationName)]is a standard approach. This cleanly associates a descriptive name with the migration for tracking.
8-13:✅ Verification successful
Confirm handling of adding new type values.
Altering an existing enum type to add
'v0.8'is fine, but ensure that any references or older code handlingentry_point_versioncan accommodate this new value without breakage. Also confirm that code referencing'v0.8'(e.g., queries, logic, or enumerations in other parts of the system) has been updated accordingly.Please verify all references to the
entry_point_versioncolumn:
🏁 Script executed:
#!/bin/bash # Search for references to `entry_point_version` usage across the codebase. rg -A 3 'entry_point_version'Length of output: 14692
Updated enum variant integration verified
The migration adding
'v0.8'to theentry_point_versionenum (in user-ops-indexer/user-ops-indexer-migration/src/m20250326_080441_entrypoint_v08.rs) is correctly integrated. Our search confirms that:
- Business logic (e.g., in src/indexer/v07/mod.rs and src/indexer/base_indexer.rs) correctly uses
EntryPointVersion::V08alongside existing variants.- Schema definitions in Swagger, proto, and other files represent
entry_point_versionas a string, ensuring compatibility with the new enum value.Please double-check that any specialized serialization or logic comparisons involving
entry_point_versionproperly handle the new'v0.8'value.user-ops-indexer/user-ops-indexer-logic/src/repository/user_op.rs (1)
207-217: Review the GROUP BY usage.Replacing
SELECT DISTINCT logs.transaction_hashwith grouping bylogs.block_number, logs.block_hash, logs.transaction_hashcan still yield unique transaction hashes, but verify that this grouping meets your data needs. If multiple logs share the same(transaction_hash, block_number, block_hash), the result should remain the same. However, consider whether plainDISTINCTmight be more readable if deduplication is all you need.user-ops-indexer/user-ops-indexer-logic/src/indexer/rpc_utils.rs (5)
12-12: Importing parity trace types.Adding
Action,CallType, andLocalizedTransactionTracehelps unify the logic across different tracing modules. No issues noted here; just ensure that other references to these types are consistent throughout the code.
86-86: New status field inCommonCallTrace.Introducing
pub status: boolclarifies whether the trace encountered an error. This is a good addition for simplifying error checks in downstream logic.
136-137: Marking reverted parents before parsing.Calling
mark_reverted_parentsensures child traces inherit their parent’s reverted status. This pre-processing is helpful for an accurate finalstatusfield. Confirm that no other methods rely on the unmodified traces, as this mutates trace data to reflect parent reverts.
151-158: Usage ofstatus: t.trace.error.is_none()looks correct.Assigning
statusbased on absence of an error matches the intended semantics. This is straightforward and aligns with typical success/failure checks in trace-based logic.
170-199: Stack-based approach inflatten_geth_trace.Switching to a stack-based traversal is clearer than a nested recursion. The while-loop popping
CallFrames from a stack avoids deep recursion. The logic to tag child calls with parent revert errors is especially important to reflect real execution outcome. Code is readable and maintainable as is.user-ops-indexer/user-ops-indexer-proto/swagger/user-ops-indexer.swagger.yaml (3)
350-361: Good addition of protobufNullValue type definitionThe addition of the
protobufNullValueenum type with appropriate description and default value correctly aligns with Protocol Buffers' standard null representation. This will help maintain consistency with the Protocol Buffers specification and improve integration with Protocol Buffer-based systems.
451-451: Appropriate field renaming for entry point indexer statusRenaming from
v07tov07_v08properly indicates that this field now covers both v0.7 and v0.8 entry points, which is consistent with the new entry point version support being added.
574-575: Good schema simplification for UserOp raw dataConverting the raw user operation data to a generic object type simplifies the schema and provides more flexibility for handling different versions of entry points. This is a cleaner approach compared to maintaining separate version-specific message types.
user-ops-indexer/user-ops-indexer-logic/src/types/user_op.rs (3)
12-12: Good import addition for JSON serializationThe import of
serde_json::jsonis appropriately added to support the refactored JSON object creation. This macro provides a more concise and readable way to create JSON structures.
156-170: Clean refactoring of V06 serialization logicThe refactoring to use the
json!macro makes the code more readable and maintainable. The structured approach clearly shows the mapping of UserOp fields to their JSON representation.
172-198: Good reuse of serialization logic for V07 and V08Combining the V07 and V08 cases is efficient since they share the same data structure. This approach reduces code duplication and makes future maintenance easier.
user-ops-indexer/README.md (3)
65-65: Good update to the V06 entry point descriptionUpdating the description to "Entrypoint v0.6 contract addresses, comma separated" correctly reflects that multiple addresses can now be specified. This improvement aligns with the code changes in settings.rs.
67-67: Good update to the V07 entry point descriptionSimilar to the V06 update, the description change to "Entrypoint v0.7 contract addresses, comma separated" properly indicates the support for multiple addresses.
68-69: Good addition of V08 entry point configurationThe addition of the V08 entry point configuration variables is well-documented and follows the same pattern as the existing entry points. The default value for the new entry point is also provided.
user-ops-indexer/user-ops-indexer-logic/src/indexer/settings.rs (4)
4-4: Good addition of CommaSeparator importThe import of
serde_with::formats::CommaSeparatoris appropriate for deserializing comma-separated values from configuration strings. This is necessary for the new functionality of supporting multiple entry point addresses.
34-47: Well-structured update to EntrypointsSettingsThe modifications to the
EntrypointsSettingsstruct properly implement support for multiple entry points per version. The use ofserde_aswithStringWithSeparator<CommaSeparator, Address>is an excellent choice for parsing comma-separated addresses from configuration strings.
102-107: Good default implementation for multiple entry pointsThe default implementation has been correctly updated to initialize the address fields as vectors, maintaining backward compatibility while adding support for the new V08 entry point.
34-108:✅ Verification successful
Verify new entry point addresses are correctly configured
The addition of V08 entry point with address "4337084D9E255Ff0702461CF8895CE9E3b5Ff108" needs verification to ensure it's the correct official entry point address for v0.8.
🌐 Web query:
What is the official EntryPoint v0.8 address for ERC-4337?💡 Result:
The official EntryPoint v0.8 contract address for ERC-4337 account abstraction is 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108[1][3][4]. This address is consistently referenced across:
- Candide's documentation as the entry point for EIP-7702-enabled UserOperations[1][3]
- The eth-infinitism/account-abstraction GitHub repository, which serves as the reference implementation for ERC-4337[4]
- Voltaire Bundler implementations handling EIP-7702 transactions[3]
The contract implements critical AA features including gas sponsorship, transaction batching, and permission management while maintaining backward compatibility with ERC-4337 infrastructure[1][4]. Developers can interact with it using standard ERC-4337 RPC methods like
eth_sendUserOperationwith added support for EIP-7702 authorization tuples[1][3].Citations:
- 1: https://docs.candide.dev/blog/eip-7702-support/
- 2: https://docs.safe.global/advanced/erc-4337/guides/permissionless-detailed
- 3: https://docs.candide.dev/wallet/bundler/rpc-methods/
- 4: https://github.com/eth-infinitism/account-abstraction
- 5: https://polygonscan.com/address/0x433700890211c1c776c391d414cffd38efdd1811
- 6: https://www.erc4337.io/docs/understanding-ERC-4337/entry-point-contract
- 7: https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/core/EntryPoint.sol
- 8: https://github.com/ethereum/ercs/blob/master/ERCS/erc-4337.md
- 9: https://etherscan.io/address/0x0576a174D229E3cFA37253523E645A78A0C91B57
- 10: https://blog.smart-contracts-developer.com/entrypoint-v0-7-0-the-new-era-of-account-abstraction-854f9f82912e
Verified V08 EntryPoint Address
The official EntryPoint v0.8 address for ERC-4337 has been confirmed as0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108per multiple authoritative sources. No changes are required for the entry point configuration inuser-ops-indexer/user-ops-indexer-logic/src/indexer/settings.rs.user-ops-indexer/user-ops-indexer-server/src/indexer.rs (6)
23-23: Double-check combined toggle logic for v0.7 & v0.8
Settingstatus.v07_v08.enabledtosettings.indexer.entrypoints.v07 || settings.indexer.entrypoints.v08may be intended as an inclusive check enabling either version. If you require enabling both versions together instead, switch to a logical AND.Do you want me to generate a script to search for downstream references to
v07_v08.enabledto confirm the intended logic?
40-40: Ensure multiple entry points are properly handled
entry_points: settings.indexer.entrypoints.v06_entry_point.clone()impliesv06_entry_pointis a vector. Verify that any code referencing this entry point properly handles multiple addresses.
49-49: Unified condition for v0.7 or v0.8
Using a single conditional statement for v0.7 or v0.8 is concise. This enables the v0.7/v0.8 indexer logic if either is set to true.
54-63: Separate v0.7 and v0.8 entry points
Constructingv07_entry_pointsandv08_entry_pointsselectively based on the settings is clear and maintainable. This pattern correctly assigns empty vectors when a version is disabled.
88-88: ProviderBuilder usage
Switching to.connectis straightforward. Confirm that the new method usage is properly tested with your RPC provider.
132-132: Reconnection logic
Re-initializingclientwith the new.connect()method after a delay is correct. This should handle transient RPC failures gracefully.user-ops-indexer/user-ops-indexer-logic/src/indexer/v06/mod.rs (5)
25-25: Support multiple entry points in v0.6
Switching from a single address to aVec<Address>aligns with multi-entry design. This is a good improvement for extensibility.
29-29: Tracking entry point at the operation level
Addingentry_point: AddressinExtendedUserOperationprovides clarity for which entry point each operation references.
60-60: Consistent usage ofentry_pointparameters
Your parse logic appropriately threads theentry_pointvalue from the caller, ensuring each sub-operation references the correct address.Also applies to: 62-62, 74-74, 86-86
95-111: User operation logs parsing
The sliding window technique that incrementsenduntil the correct log is found is sensible. A short-circuit for unmatched logs is implicitly handled by your bounds-check. This logic looks correct.
156-156: Use ofuser_op.entry_point
Referencinguser_op.entry_pointensures each user operation is tied to its own entry point. This is coherent and should prevent mismatched event parsing.Also applies to: 159-160, 164-164, 171-171, 182-182, 193-193, 209-209
user-ops-indexer/user-ops-indexer-logic/src/indexer/v07/mod.rs (8)
13-13: Importingaddress!macro
Includingaddressfromalloy::primitivessuggests new usage for a sentinel address. Ensure you have relevant tests for that logic.
26-27: Separate fields for v0.7 vs. v0.8
Maintaining distinct vectorsv07_entry_pointsandv08_entry_pointsis flexible and well-scoped. This aligns with your multi-version approach.
31-31: Explicitentry_pointin ExtendedUserOperation
Storing the entry point at the operation level is consistent with v06 logic.
39-39: Combination version string
DeclaringVERSIONas"v0.7-v0.8"is a practical approach to unify logging and identification for both versions.
66-66: Consistent entry point usage
Forwarding theentry_pointparameter ensures correct event matching. Good consistency with v06.Also applies to: 68-68, 80-80, 92-92
101-117: Log matching and boundary checks
The loop approach is parallel to v06 usage. It’s a clear way to assign each user operation logs slice.
213-216: Special factory address check
Ignore the sentinel address"7702..."to treat it as no factory. This logic is straightforward, but confirm your use case.
220-220: Extracting user logs boundaries
This matches the v06 approach, ensuring that logs outside the relevant entry point or paymaster are exempt.user-ops-indexer/user-ops-indexer-logic/src/indexer/base_indexer.rs (13)
75-77: Great addition for multi-entry point support.Introducing
entry_pointsandmatches_entry_pointin the trait cleanly accommodates multiple entry points without complicating downstream logic.
85-87: Enhanced parameter clarity.Adding
entry_pointandbundle_logsparameters toparse_user_opsmakes the function’s responsibilities and inputs explicit, thereby improving maintainability.
103-103: Consistent filtering for multiple addresses.Using
self.entry_points()in the filter reflects the multi-entry point design, ensuring all relevant addresses are included.
367-384: Safe slicing approach.Slicing with
[i + 1..]is valid in Rust, even wheniis the last index (it yields an empty slice). No out-of-bounds risk here, so this looks fine.
386-410: Robust logic for retrieving calldatas.Falling back to call traces when the transaction is indirect or holds multiple bundles is a good approach. Properly checks each trace, matching entry points and handler calldata.
412-418: Ensures log-calldata parity.Exiting early if
calldatas.len()doesn’t matchvec_bundle_logs.len()avoids silent mismatches and data corruption.
438-438: Helpful new log statement.Printing the number of parsed user ops offers quick insight into how many were processed. No further issues.
471-481: Effective fixture-loading in tests.Relying on fixture files to load JSON responses is a robust approach for test data. Includes clear I/O handling and avoids cluttering test code with fixtures.
483-489: Mocking RPC responses.
mock_rpc_with_responsesprovides a flexible structure to simulate various scenarios, enhancing test reliability without real network calls.
494-495: Integration with fixture-based client.Creating the client via
mock_rpc_with_responses("handle_tx_v06_ok")ensures each test is strictly defined by the loaded fixture, simplifying debugging.
505-507: Configuring entry points for v06.Explicitly passing the entry points in the
IndexerV06construction is consistent with the multi-entry point architecture.
562-576: Coverage with debug and trace modes.Testing both
TraceClient::DebugandTraceClient::Tracehelps confirm consistent behavior across different node trace frontends.
634-648: Proper v07 usage.Creating and verifying the v07 indexer with separate entry point arrays confirms that the combined logic (v07 plus any v08 placeholders) doesn’t regress.
Summary by CodeRabbit
New Features
Documentation
Chores