[General] Lack of error in flatCallTracer

[MRabenda]

Team or Project

MetaMask

Environment

Mainnet

L2 block number

2558830

Provide a brief description of the functionality you're trying to implement and the issue you are running into.

Today we encountered an issue where a transaction failed but showed no errors in the traces.

In our pipeline, we use the following request:

{
  "id": 0,
  "method": "debug_traceBlockByNumber",
  "params": [
    "$BLOCK_NUMBER",
    {
      "tracer": "flatCallTracer",
      "timeout": "60s"
    }
  ],
  "jsonrpc": "2.0"
}

For simplification, here is an example of what we get when tracing the transactions:
Transaction Hash: 0x1d55f591f2dec2db4ede9dfdf1e921c38f315daeddfc5f4f690ab13c1fa0cc72
https://era.zksync.network/tx/0x1d55f591f2dec2db4ede9dfdf1e921c38f315daeddfc5f4f690ab13c1fa0cc72
Status: Failed as shown in the explorer.

Attached, you will find the response for the request below, where the transaction indeed does not have an error:

{
  "id": 0,
  "method": "debug_traceTransaction",
  "params": [
    "0x1d55f591f2dec2db4ede9dfdf1e921c38f315daeddfc5f4f690ab13c1fa0cc72",
    {
      "tracer": "flatCallTracer",
      "timeout": "60s"
    }
  ],
  "jsonrpc": "2.0"
}

Here are other transactions without corresponding errors when tracing:
Block 2558830 -> Tx: 0x1d55f591f2dec2db4ede9dfdf1e921c38f315daeddfc5f4f690ab13c1fa0cc72 (example listed above)
Block 2637427 -> Tx: 0xacb4bb951661950a9cb0df04f3e5ce8dce37c98a684924a07e1bab5f118202c8
Block 2610752 -> Tx: 0x38822e3ef0298e9131790333356986d5051784861e43e602da5a9b97b8c66118
Block 2579103 -> Tx: 0x45634aa7756181707f1b8e6ef6404069c4f2c4506f20466ed637850a113237ab
Block 2642447 -> Tx: 0x94fc982c4c2fb8146912f15a362bb5292e8094a77ec68c6be243e5861cec2321
Let me know if you need any further information. I can also open a GH issue if it’s a better way to report this.

Repo Link (Optional)

No response

Additional Details

No response

[gleenai[bot]]

It appears that the issue you're encountering with the flatCallTracer not showing errors in the transaction traces, despite the transactions failing, might be related to the specific tracer configuration or limitations in the tracing method itself. The flatCallTracer is designed to provide a simplified view of call traces, which might not include detailed error information or might miss certain types of errors that are otherwise visible in the transaction status on the block explorer.

For a more detailed investigation and to potentially capture the errors that are not appearing in your current traces, you might consider using a different tracer configuration that includes more comprehensive error reporting. Alternatively, you could adjust the tracer settings to ensure it captures all relevant transaction details, including errors.

If the issue persists and you believe it to be a bug or a limitation of the current tracing tools on ZKsync, opening a GitHub issue in the ZKsync developers discussions would be a suitable next step. This would allow the development team to look into the matter more closely and provide a fix or enhancement if necessary.

For further technical discussions or to seek more in-depth assistance, you can visit the ZKsync developers discussions on GitHub.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[JackHamer09]

Hey @MRabenda, thanks for submitting the issue, I'll investigate it and get back to you ASAP.

[JackHamer09]

@MRabenda It seems all the mentioned transactions have run out of gas. There might be a bug on the server side causing the error field to be missing; we're actively investigating this issue (bug report).

Quick Fix:

As a temporary workaround, you can validate the gas limit against the gas used for the top item. If gasUsed is >99.99% of gas (the gas limit), it's very likely that the transaction has failed.

Example:

{
    "jsonrpc": "2.0",
    "result": [{
        "action": {
            "gas": "0x1063d5", // Gas limit (1 074 133)
            ...
        },
        "result": {
            "gasUsed": "0x1063c9", // Gas used (1 074 121)
            ...
        },
        ...,
    }]
}

[MRabenda]

From our end we would save that data in our datalake, so we would like to be sure that these are as accurate as possible

[JackHamer09]

We're tracking this issue, but can't promise on the exact timelines, unfortunately.

[uF4No]

FYI @MRabenda, this issue is being tracked in matter-labs/zksync-era#3394

[bxpana]

@MRabenda going to mark this as answered and can follow up in the issue matter-labs/zksync-era#3394. If anything else comes up please let us know