graphprotocol / graphprotocol/graph-node
[Feature] Display the full JSON-RPC call in the logs that failed
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 3.2k
- Forks
- 1.1k
- Avg merge
- 4d 1h
- Merged PRs (30d)
- 1
Description
Currently if something goes wrong with a JSON RPC call (eth-calls, decoding, etc) there is just a message like this displayed:
failed to process trigger: block #21041413 (0x0000…b378), transaction a44fa1857fa5448419ff94682de1ffeccaa74eb0d6dc9d0de8fe37c6c2a90746: Decoding function outputs for the call Function { name: "withdraw", inputs: [], outputs: [Param { name: "", kind: Uint(256), internal_type: None }], constant: None, state_mutability: NonPayable } failed, raw output: : Invalid name: please ensure the contract and method you're calling exist! failed to decode empty bytes. if you're using jsonrpc this is likely due to jsonrpc returning 0x in case contract or method don't exist
(From this example subgraph: https://thegraph.com/hosted-service/subgraph/bsamuels453/yearn-fantom-validation?selected=logs, deployment id: QmNhTkng5LLvdCXbK6JSoeU8tSW18wo3tPpm5mMM3Sd4FY)
This alone does not provide enough information to reproduce.
What is the expected behavior?
It would be great to have the exact JSON RPC call written in the logs so we can reproduce and troubleshoot the underlying issue.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the JSON-RPC failure logging path in graph-node and reproduce the example failure from the issue. Trace the failed eth-call or decoding operation to determine where its request details are available; done means the exact JSON-RPC call is included in logs for comparable failures and remains useful for reproducing the underlying error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend-api-design, observability
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100