The node failed to use trace. Procedure

[blocknodehub]

curl -s -X POST -H "Content-Type: application/json" -d '{"method":"debug_traceBlockByHash","params":["0x974718afc17e6d519ca661c18c24ab62914365d96f58e283610b7b7336da2ffb", {"tracer": "callTracer"}],"id":1,"jsonrpc":"2.0"}' http://127.0.0.1:9944 | jq
{
"jsonrpc": "2.0",
"error": {
"code": -32603,
"message": "Block hash not found"
},
"id": 1
}

curl -s -X POST -H "Content-Type: application/json" -d '{"method":"debug_traceBlockByNumber","params":["6039371", {"tracer": "callTracer"}],"id":1,"jsonrpc":"2.0"}' http://127.0.0.1:9944
{"jsonrpc":"2.0","result":[{"from":"0x17b439b73e255eef5efa03d7a9b482821128bf74","gas":"0xfa0","gasUsed":"0x5208","type":"CALL","to":"0x85f3ed7f017ad096e172dd1ba62d428b6e44fabf","input":"0x","output":"0x","value":"0x8700cc75770000"},{"from":"0x17b439b73e255eef5efa03d7a9b482821128bf74","gas":"0xfa0","gasUsed":"0x0","type":"CALL","to":"0x996f04fd835a320681bf5f6307f5c619df449128","input":"0x","output":"0x","value":"0x6ce05fe7c96000"},{"from":"0x17b439b73e255eef5efa03d7a9b482821128bf74","gas":"0xfa0","gasUsed":"0x0","type":"CALL","to":"0xad62ee9c882a963c0139e1a4a25bf3efab01567e","input":"0x","output":"0x","value":"0x8700cc75770000"},{"from":"0xe93685f3bba03016f02bd1828badd6195988d950","gas":"

[rrozek]

any news on this one? ETA on delivery?

For some context, this prevents subsquid indexer from indexing chain traces which are of significant value to some projects based on data provided by subsquid archives :)
As subsquid is the go-to solution for accessing data from Moonbeam chain, no full support hurts the whole ecosystem

[elfedy]

@blocknodehub could you clarify what block and network does the 0x974718afc17e6d519ca661c18c24ab62914365d96f58e283610b7b7336da2ffb hash come from?

Looked for block 6039371 on our networks and the hash does not match:

• For moonbeam we have not reached that height
• For moonriver, block hash is 0x7318f31308d24b0f62e042ee637e11ee4cd5e0ba157c79fc3767771553896f82.
• For moonbase, block hash is 0x4b000e0c72cbe90de6c9ca4423c3d73f1a1afe36e54aadb97108345da0ba0565.

Could not reproduce the issue with neither

[elfedy]

There is a transaction with the 0x974718afc17e6d519ca661c18c24ab62914365d96f58e283610b7b7336da2ffb hash on Moonriver. If that's your intended use case, then it is not supported for debug_traceBlockByHash by neither Moonbeam nor Geth. You cannot get a full block trace directly from one of it's transaction hashes. You need to either use debug_traceTransaction for that specific transaction trace, or use the block hash for when that transaction ocurred to get the full block trace

[librelois]

@rrozek For the moment, we don't know what the bug is, let alone how to reproduce it.
We'd be happy to implement what subsquid needs, but we need a more precise description of the requirement.

[tmcgroul]

@librelois actually subsquid has dropped moonbeam traces support because of another issue - #2626
internally we run some validation logic and in this case number of transactions (36) doesn't match to number of traces (35) which is invalid behaviour from our point of view 🤷‍♂️

[RomarQ]

Issue #2626 has been fixed. As @elfedy has mentioned, you cannot debug_traceBlockByHash with a transaction hash, it needs to be a block hash.