Skip to content

Conversation

@incrypto32
Copy link
Member

Subgraphs would stall when block cache is truncated because ancestor_block returned None when the requested ancestor wasn't in cache.

This PR adds RPC/Firehose fallback for ancestor_block logic

@fordN fordN requested a review from lutter January 8, 2026 16:47
When ancestor_block falls back to RPC due to cache deserialization failures,
fetch full blocks with receipts instead of light blocks. Empty receipts caused
missing block handler call triggers and log triggers.
@incrypto32
Copy link
Member Author

@lutter Integration cluster caught an issue i have updated the PR with the fix, i was using a Light Block for the rpc fall back for ancestor_block and was keeping an empty array for transaction_receipts, this was not right. So i've added a commit that uses the full block instead.

}
None => {
// Cache miss - fall back to walking the chain via parent_ptr() calls.
// This provides resilience when the block cache is empty (e.g., after truncation).
Copy link
Collaborator

Choose a reason for hiding this comment

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

The one downside with this is that if ancestor_block is called with an invalid hash, we run both a db query and make an rpc call. But that's probably not very common

@incrypto32 incrypto32 merged commit ee48083 into krishna/alloy-abi-fixes Jan 14, 2026
@incrypto32 incrypto32 deleted the krishna/ancestor-block-rpc-fallback branch January 14, 2026 10:05
incrypto32 added a commit that referenced this pull request Jan 14, 2026
…ehose or RPC on deserialization errors (#6240)

* Add warning logs on block deserialization failures

* add Firehose/RPC fallback for stale block cache in ancestor_block

* chain/ethereum: Fix ABI conversion issues in alloy migration

* store, chain/ethereum: Handle pre-Byzantium receipt status correctly

* graph: Normalize ABI JSON to handle undefined stateMutability

Some ABIs contain "undefined" as a stateMutability value, which is not
part of the official Solidity ABI specification. The spec only defines
four valid values: pure, view, nonpayable, and payable.

Alloy's StateMutability enum strictly follows the spec and rejects
"undefined" during deserialization, causing subgraph deployment failures
with: unknown variant `undefined`, expected one of `pure`, `view`,
`nonpayable`, `payable`

This adds a normalize_abi_json() function that preprocesses ABI JSON
before deserialization, replacing "undefined" with "nonpayable" (the
default state mutability). This handles non-compliant ABIs gracefully
while maintaining spec compliance.

Also adds a unit test to verify the normalization works correctly.

🤖 Generated with Claude Code
Co-Authored-By: Claude <[email protected]>

* graph: Handle duplicate constructors in ABIs

Extends normalize_abi_json() to also remove duplicate constructors from ABIs.

Some non-compliant ABIs contain multiple constructor entries (e.g., DolomiteMargin
ABI has two constructors, likely from incorrectly merged contract ABIs). Alloy's
JsonAbi only allows one constructor and fails with 'duplicate field self.constructor'
when encountering duplicates.

ethabi's Contract type silently handled this by only storing one constructor
(the last one encountered during deserialization).

The fix keeps only the first constructor and removes any subsequent ones, matching
the Solidity spec that a contract can only have one constructor.

Fixes subgraph QmacPbft3reGGGL4VBzrZCKHeLpRgU9X2wUJjvPBVweyRV deployment.

* extend normalizer to handle all alloy parsing incompatibilities

* Add fallback for ancestor_block to handle cache truncation (#6262)

* ethereum: Add RPC fallback for ancestor_block to handle cache truncation

* ethereum: Extract walk_back_ancestor logic and add tests

* ethereum: Fetch full blocks with receipts in ancestor_block RPC fallback

When ancestor_block falls back to RPC due to cache deserialization failures,
fetch full blocks with receipts instead of light blocks. Empty receipts caused
missing block handler call triggers and log triggers.

---------

Co-authored-by: Claude <[email protected]>
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.

3 participants