[Bug] eth_call Errors Cause Infinite Loop in Local and Remote Graph Node
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- rust, typescript
- Lĩnh vực
- backend, blockchain
Hướng nghiên cứu
Bắt đầu với việc xử lý retry eth_call của Graph Node và các log SubgraphInstanceManager được hiển thị trong báo cáo. Tái hiện lỗi bằng ví dụ do-while được cung cấp và lỗi thực thi VM đã ghi nhận. Hoàn tất khi một eth_call thất bại được xử lý mà không retry vô thời hạn, cho phép quá trình lập chỉ mục tiếp tục.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Bug report
Description:
I’m facing an issue while developing a subgraph locally and on a remote Graph Node. When my handler function executes an eth_call and encounters an error like "VM execution error", the indexing process gets stuck. Instead of moving forward, the node repeatedly sends the same eth_call request, encountering the same error over and over, resulting in an infinite loop.
Expected Behavior:
When an eth_call results in an error, such as "VM execution error", the Graph Node should handle the error gracefully by logging it and then continuing with the indexing process, avoiding getting stuck in a loop.
Actual Behavior:
The Graph Node enters an infinite loop, where it keeps retrying the same eth_call that causes the "VM execution error". This halts the indexing process, preventing any further progress.
Code Example:
// Function to get swap info from a contract
export function getSwapInfoNoWithdrawFee(swap: Address): SwapInfo {
let swapContract = SwapFlashLoanNoWithdrawFee.bind(swap)
let tokens: Address[] = []
let balances: BigInt[] = []
let t: ethereum.CallResult<Address>
let b: ethereum.CallResult<BigInt>
let i = 0
// Loop through token indices to get token addresses and balances
do {
t = swapContract.try_getToken(i)
b = swapContract.try_getTokenBalance(i)
if (!t.reverted && t.value.toHexString() != ZERO_ADDRESS) {
tokens.push(t.value)
}
if (!b.reverted) {
balances.push(b.value)
}
i++
} while (!t.reverted && !b.reverted)
// Get additional swap info
let lpTokenSupply = getTotalSupply(swap)
return {
tokens,
balances,
A: swapContract.getA(),
swapFee: swapContract.swapStorage().value4,
adminFee: swapContract.swapStorage().value5,
withdrawFee: BigInt.fromI32(0),
virtualPrice: swapContract.getVirtualPrice(),
owner: swapContract.owner(),
lpToken: swapContract.swapStorage().value6,
lpTokenSupply,
}
}
Problem Details:
The issue occurs in the do-while loop, where the function iterates through token indices to retrieve token addresses and balances using the try_getToken and try_getTokenBalance methods.
When the contract returns an error (e.g., "VM execution error" or "Reverted Out of range"), the loop should ideally stop or handle the error gracefully. However, instead, the Graph Node enters an infinite loop, continually retrying the same eth_call, causing the node to get stuck and preventing it from continuing the indexing process.
Steps to Reproduce:
- Deploy a subgraph that includes a handler function making an
eth_callto a contract. - Trigger an
eth_callfailure (e.g., by passing an out-of-range value or an invalid token index). - Observe the behavior of the Graph Node as it repeatedly retries the
eth_calland logs the same error.
Logs:
ERRO Ethereum node returned an error when calling function "getToken" of contract "SwapFlashLoanNoWithdrawFee": RPC error: Error { code: ServerError(-32015), message: "VM execution error.", data: Some(String("Reverted Out of range")) }, sgd: 1, subgraph_id: QmZSSowKwzADwD6wpXx7DBEkkKYBFmKG7VNZtcqB3HXmsk, component: SubgraphInstanceManager
WARN Trying again after eth_call RPC call for block #16199484 (bab0ef7134d84a23819c8c1305c061e8e23858f3a78759efbcc7f5889798ee95) failed (attempt #10) with result Err(Web3Error(Rpc(Error { code: ServerError(-32015), message: "VM execution error.", data: Some(String("Reverted Out of range")) }))), provider: fuse-rpc-0, sgd: 1, subgraph_id: QmZSSowKwzADwD6wpXx7DBEkkKYBFmKG7VNZtcqB3HXmsk, component: SubgraphInstanceManager
Additional Information:
Interestingly, when I deploy the same subgraph to the hosted Graph Node on Graph Studio, the error is handled differently. Although the same eth_call error occurs, the indexing process continues without issues. It seems the hosted service has additional error-handling mechanisms that are not present in the local or remote Graph Node setup.
Proposed Solution:
It would be beneficial if the local and remote Graph Node instances could implement similar error-handling behavior as the hosted Graph Node on Graph Studio. Specifically, the node should be able to catch these eth_call errors and continue indexing without getting stuck in an infinite loop.
Steps to Resolve:
- Introduce a mechanism to handle specific
eth_callerrors, such as logging the error and skipping the problematic block or transaction. - Optionally, provide configuration options to control the retry behavior or to handle specific error codes in a customizable way.
Relevant log output
No response
IPFS hash
No response
Subgraph name or link to explorer
No response
Some information to help us out
- Tick this box if this bug is caused by a regression found in the latest release.
- Tick this box if this bug is specific to the hosted service.
- I have searched the issue tracker to make sure this issue is not a duplicate.
OS information
None
- Ngôn ngữ chính
- Rust
- Star
- 3.2k
- Fork
- 1.1k
- Merge trung bình
- 4 ngày 1 giờ
- Pull request đã merge (30 ngày)
- 1
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của graphprotocol/graph-node
-
current: include emits an all-null bucket for dimensionless aggregations, nulling the whole response Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
graphprotocol/graph-node#6719 ·
-
RUSTSEC-2026-0194: Quadratic run time when checking a start tag for duplicate attribute names Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
graphprotocol/graph-node#6673 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
graphprotocol/graph-node#6650 · 1 bình luận ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
graphprotocol/graph-node#6722 ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
graphprotocol/graph-node#6721 ·
Tất cả issue của graphprotocol/graph-node
Issue tương tự
-
risk:low runtime status:in-progress type:test
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
zeroclaw-labs/zeroclaw#11023 ·
-
good first issue refactor
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
kwakseongjae/auto-hwp#319 ·
-
area:cli bug filter-quality good first issue priority:medium
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
bevyengine/bevy#25861 ·