fix: fixes debug_traceBlockByNumber response to not be null for a transaction with no internal calls

[simzzz]

Description

Ensures that debug_traceBlockByNumber and debug_traceTransaction with callTracer always return a calls field as an array, never null or undefined, even when transactions have no internal calls.

Related issue(s)

Fixes #4386

Testing Guide

1. Call debug_traceBlockByNumber for a block that contains a transaction with no calls such as 0x522ba41 on mainnet
2. Make sure result is an object with an empty calls array instead of null

Changes from original design (optional)

N/A

Additional work needed (optional)

N/A

Checklist

• I've assigned an assignee to this PR and related issue(s) (if applicable)
• I've assigned a label to this PR and related issue(s) (if applicable)
• I've assigned a milestone to this PR and related issue(s) (if applicable)
• I've updated documentation (code comments, README, etc. if applicable)
• I've done sufficient testing (unit, integration, etc.)

[github-actions]

Test Results

 20 files  ±0  265 suites  ±0   20m 54s ⏱️ -45s
764 tests  - 1  760 ✅ +3  4 💤 ±0  0 ❌  - 4 
780 runs  ±0  776 ✅ +4  4 💤 ±0  0 ❌  - 4 

Results for commit 6debd0c. ± Comparison against base commit dcba3d0.

This pull request removes 1 test.

"after all" hook in "@release @web-socket-batch-1 JSON-RPC requests validation" ‑ RPC Server Acceptance Tests Acceptance tests @release @web-socket-batch-1 JSON-RPC requests validation "after all" hook in "@release @web-socket-batch-1 JSON-RPC requests validation"

♻️ This comment has been updated with latest results.

[quiet-node]

I can't seem to reproduce this issue. Block 0x5067CB1 (mentioned in the associated ticket) contains two EthereumTransaction entries, one failed due to a wrong nonce and one succeeded. Using your updated version in this PR and the main branch (without this update), running debug_traceBlockByNumber with that block as a parameter returns a non-null response in both cases:

{
    "result": [
        {
            "txHash": "0xa74c140aedec484c5c6cb559aecd75386d15cbafcc3e55c90d5302adbea86337",
            "result": {
                "type": "CALL",
                "from": "0x339d413ccefd986b1b3647a9cfa9cbbe70a30749",
                "to": "0x3c2269811836af69497e5f486a85d7316753cf62",
                "value": "0x0",
                "gas": "0xaae60",
                "gasUsed": "0x88b80",
                "input": "0x3161b7f600000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000016f000000000000000000000000000000000000000000000000000002109014be420000000000000000000000000000000000000000000000000000000005f86e6b0000000000000000000000000000000000000000000000000000000000000010",
                "output": "0x",
                "calls": [
                    {
                        "type": "DELEGATECALL",
                        "from": "0x3c2269811836af69497e5f486a85d7316753cf62",
                        "to": "0x4ee2f9b7cf3a68966c370f3eb2c16613d3235245",
                        "gas": "0xa1b93",
                        "gasUsed": "0x2a78",
                        "input": "0x3161b7f600000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000016f000000000000000000000000000000000000000000000000000002109014be420000000000000000000000000000000000000000000000000000000005f86e6b0000000000000000000000000000000000000000000000000000000000000010",
                        "output": "0x",
                        "value": "0x0"
                    }
                ]
            }
        }
    ],
    "jsonrpc": "2.0",
    "id": 1
}

Am I missing something or it's just too late to use that block now?

[quiet-node]

Couple of questions left on the associated ticket as well #4386 (comment)

[simzzz]

@quiet-node hmm, I also can't reproduce it along with other examples I had written down. (perhaps it was a bug on MN side due to modularization, that is now fixed?). Nevertheless, I still think we should fix the response format for this particular case. I will try to find another example.

[quiet-node]

@quiet-node hmm, I also can't reproduce it along with other examples I had written down. (perhaps it was a bug on MN side due to modularization, that is now fixed?). Nevertheless, I still think we should fix the response format for this particular case. I will try to find another example.

Yeah let's bring this up to a parking lot session and discuss as a team

[konstantinabl]

Left some nit comments

[quiet-node]

LGTM

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

@@            Coverage Diff             @@
##             main    #4440      +/-   ##
==========================================
- Coverage   96.23%   96.22%   -0.01%     
==========================================
  Files         121      121              
  Lines       20001    19998       -3     
  Branches     1756     1751       -5     
==========================================
- Hits        19247    19244       -3     
  Misses        735      735              
  Partials       19       19              

Flag	Coverage Δ
config-service	98.80% <ø> (ø)
relay	91.17% <80.00%> (-0.01%)	⬇️
server	88.85% <ø> (ø)
ws-server	98.04% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
packages/relay/src/lib/debug.ts	99.37% <100.00%> (-0.01%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.