Output format inconsistent between JS and native tracers in traceBlock*

[3605031]

I tried the Debug_traceBlockByNumber endpoint and got different json structure. For blocks that were less than 30 mins from tips, it seemed the traceCalls results are wrapped inside the "result" key. However it is not the same for blocks that were more than 30 mins from tips. These calls were made using quicknode which claims they are using Geth 1.10

[jsvisa]

Maybe is a question about rpc response of quicknode, you can paste the raw request/response here for more information.

[s1na]

For blocks that were less than 30 mins from tips, it seemed the traceCalls results are wrapped inside the "result" key.

But there were results only not nested? Because in case of an error the result will be empty and there will be instead. BTW you didn't happen to use a JS tracer?

[s1na]

I've noted an inconsistency between JS and native tracers introduced here: #24283. Basically in case an error is encountered for any tx, traceBlock will return nil result and the error for native tracers, vs. it returning partial results for JS tracers.

go-ethereum/eth/tracers/api.go

Lines 636 to 639 in 3a79a99

	res, err := api.traceTx(ctx, msg, txctx, blockCtx, statedb, config)
	if err != nil {
	return nil, err
	}

[3605031]

I used the call tracer. Here is the output.

Looks like I can't reproduce the issue anymore with quicknode, might be a format upgrade but before, each transaction trace wouldn't be nested inside the "result" key (for blocks > 30 mins from tip) i.e

"result": [
        {
                "from": "0xb2ca9495f3e1972801c12a964fa344a6630f427a",
                "gas": "0x9858",
                "gasUsed": "0x5208",
                "to": "0x94a10f3ed4b8aefda9385be8fc63f76453f37b64",
                "input": "0x",
                "value": "0xaa87bee538000",
                "type": "CALL"
        },

instead of

"result": [
        {
            "result": {
                "from": "0xb2ca9495f3e1972801c12a964fa344a6630f427a",
                "gas": "0x9858",
                "gasUsed": "0x5208",
                "to": "0x94a10f3ed4b8aefda9385be8fc63f76453f37b64",
                "input": "0x",
                "value": "0xaa87bee538000",
                "type": "CALL"
            }
        },

[s1na]

Ok I will re-use this issue for the inconsistency I mentioned above. But please write if you saw the original issue happening again.