Skip to content

parser: make Parser2 network-generic (unblock raindex AnyNetwork)#521

Merged
thedavidmeister merged 1 commit into
mainfrom
2026-05-27-parser-network-generic
May 27, 2026
Merged

parser: make Parser2 network-generic (unblock raindex AnyNetwork)#521
thedavidmeister merged 1 commit into
mainfrom
2026-05-27-parser-network-generic

Conversation

@thedavidmeister
Copy link
Copy Markdown
Contributor

@thedavidmeister thedavidmeister commented May 27, 2026

Why

Parser2/ParserV2 and the internal eth_call were bound to P: Provider, which defaults to Provider<Ethereum>. raindex is multi-chain and builds Provider<AnyNetwork> providers; it cannot pass them to parse_text/parse/parse_pragma — the compiler reports Provider<Ethereum> is required but only Provider<AnyNetwork> is implemented. This blocks raindex's crates.io cutover (raindex_common::add_order calls parse_text(.., &provider) with an AnyNetwork provider).

What

Parameterise over N: Network (P: Provider<N>) and build the request via alloy::network::TransactionBuilder so N::TransactionRequest is used instead of the hardcoded Ethereum TransactionRequest. Parsing is a plain eth_call with no network-specific fields, so this only relaxes the bound — existing Ethereum-provider callers are unaffected (N is inferred).

Verification

  • cargo test -p rainlang_parser: 4 pass (Ethereum-provider mocks, unchanged).
  • cargo check --workspace (native): clean.
  • test-wasm-build: clean (both #[cfg] trait variants).

Once merged, Package Release republishes the parser; raindex pins the new version to finish its cutover. Relates to rainlang#519/#520.

Summary by CodeRabbit

  • Refactor
    • Enhanced parser architecture to support multiple blockchain networks more flexibly, improving extensibility for future network integrations.

Review Change Stack

`eth_call` and the `Parser2`/`ParserV2` methods were bound to `P: Provider`,
which defaults to `Provider<Ethereum>`. Callers using a `Provider<AnyNetwork>`
(e.g. raindex, which is multi-chain and builds AnyNetwork providers) could not
pass them to `parse_text`/`parse`/`parse_pragma` — the bound required
`Provider<Ethereum>`.

Parameterise over `N: Network` (`P: Provider<N>`) and build the call via
`TransactionBuilder` so `N::TransactionRequest` is used. Parsing is a plain
`eth_call` with no network-specific fields, so this is purely a relaxation of
the bound; existing Ethereum-provider callers are unaffected (N is inferred).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@thedavidmeister thedavidmeister self-assigned this May 27, 2026
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 27, 2026

📝 Walkthrough

Walkthrough

This PR generalizes the Parser2 trait and ParserV2 implementation to accept network-typed providers from the alloy library. The eth_call helper now constructs transaction requests via the provider's associated network type, allowing callers to specify their network when parsing on-chain data.

Changes

Network-generic parser API

Layer / File(s) Summary
Helper function and trait interface
crates/parser/src/v2.rs
eth_call now accepts Provider<N> and builds transactions using N::TransactionRequest. The Parser2 trait methods are updated to require N: Network and P: Provider<N> in both non-wasm and wasm configurations.
Parser implementation matching network-generic trait
crates/parser/src/v2.rs
ParserV2 implementations of Parser2 are updated for both compile targets, with parse and parse_pragma async signatures now using N: Network and Provider<N>.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

  • rainlanguage/rainlang#511: Both PRs refactor the on-chain parser client API around alloy's Provider, with this PR further generalizing method signatures over alloy::network::Network.

Poem

A network type now flows through the parse,
Once fixed, now generic—a flexible pass.
Providers adapt with the caller's own chain,
Our parser speaks many tongues, network-agnostic and plain. 🐰✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 22.22% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately and specifically describes the main change: making Parser2 network-generic to support AnyNetwork, which is the primary objective of the PR.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch 2026-05-27-parser-network-generic

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
crates/parser/src/v2.rs (1)

26-57: ⚡ Quick win

Add one regression test for Provider<AnyNetwork>.

This API change is specifically meant to unblock Provider<AnyNetwork>, but the tests in this file still only cover the default mocked provider path. A small test that type-checks and calls parse_text/parse_pragma_text with an actual Provider<AnyNetwork> would lock in the contract this PR is introducing and catch future regressions early.

🤖 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 `@crates/parser/src/v2.rs` around lines 26 - 57, Add a small regression test
that type-checks and invokes the new API with a real Provider<AnyNetwork>:
create a test that constructs a Provider<AnyNetwork> (or uses the existing
provider test helper configured for AnyNetwork), calls Parser::parse_text and
Parser::parse_pragma_text (verifying returned types parse2Return and
Vec<Address>/parsePragma1Return as appropriate), and asserts the results or that
calls complete successfully; ensure the test references the parse_text and
parse_pragma_text methods and uses Provider<AnyNetwork> so the compiler will
catch regressions to the generic Provider<AnyNetwork> API.
🤖 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 `@crates/parser/src/v2.rs`:
- Around line 26-57: Add a small regression test that type-checks and invokes
the new API with a real Provider<AnyNetwork>: create a test that constructs a
Provider<AnyNetwork> (or uses the existing provider test helper configured for
AnyNetwork), calls Parser::parse_text and Parser::parse_pragma_text (verifying
returned types parse2Return and Vec<Address>/parsePragma1Return as appropriate),
and asserts the results or that calls complete successfully; ensure the test
references the parse_text and parse_pragma_text methods and uses
Provider<AnyNetwork> so the compiler will catch regressions to the generic
Provider<AnyNetwork> API.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: c0dc1362-fb76-430f-b3b8-a4fb8ff1a3f7

📥 Commits

Reviewing files that changed from the base of the PR and between 77ffb9f and 6cab975.

📒 Files selected for processing (1)
  • crates/parser/src/v2.rs

@thedavidmeister thedavidmeister merged commit 03876ac into main May 27, 2026
8 checks passed
@github-actions
Copy link
Copy Markdown
Contributor

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

  • Simple bug fixes, typos, or minor refactoring
  • Single-purpose changes affecting 1-2 files
  • Documentation updates
  • Configuration tweaks
  • Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

  • Fix typo in variable name
  • Update README with new instructions
  • Adjust configuration values
  • Simple one-line bug fixes
  • Import statement cleanup

Medium (M)

Characteristics:

  • Feature additions or enhancements
  • Refactoring that touches multiple files but maintains existing behavior
  • Breaking changes with backward compatibility
  • Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

  • Add new feature or component
  • Refactor common utility functions
  • Update dependencies with minor breaking changes
  • Add new component with tests
  • Performance optimizations
  • More complex bug fixes

Large (L)

Characteristics:

  • Major feature implementations
  • Breaking changes or API redesigns
  • Complex refactoring across multiple modules
  • New architectural patterns or significant design changes
  • Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

  • Complete new feature with frontend/backend changes
  • Protocol upgrades or breaking changes
  • Major architectural refactoring
  • Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

  • Test coverage impact: More comprehensive test changes lean toward larger classification
  • Risk level: Changes to critical systems bump up a size category
  • Team familiarity: Novel patterns or technologies increase complexity

Notes:

  • the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
  • the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
  • do not include any additional text, only the size classification
  • your assessment comment must not include tips or additional sections
  • do NOT tag me or anyone else on your comment

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 27, 2026

Tip

For best results, initiate chat on the files or code changes.

SIZE=S

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant