ethereum-optimism / ethereum-optimism/optimism

trace_filter returns empty for single-block ranges

Open
#18,406 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
6.5k
Forks
4k
Avg merge
2d 15h
Merged PRs (30d)
145

Description

**Bug Description**

After a recent upstream upgrade to the Optimism op-reth tracing client, `trace_filter` calls on Optimism mainnet return an empty result (`[]`) when `fromBlock` and `toBlock` are set to the same block, even though the block contains valid transactions and internal traces.

Example block: `0x89A5645` (decimal 144332357)
Explorer: https://optimistic.etherscan.io/block/144332357

This behavior began around **16:30 UTC**, which aligns with the time the upstream upgrade was deployed.

If the query range is expanded by one block (`toBlock = fromBlock + 1`), valid traces are returned.

---

**Steps to Reproduce**

1. Send a trace_filter request with a single-block range:

```json
{
"jsonrpc": "2.0",
"id": 1,
"method": "trace_filter",
"params": [{
"fromBlock": "0x89A5645",
"toBlock": "0x89A5645"
}]
}
```

**Result:** `[]`

2. Expand the range by one block:

```json
{
"jsonrpc": "2.0",
"id": 1,
"method": "trace_filter",
"params": [{
"fromBlock": "0x89A5645",
"toBlock": "0x89A5646"
}]
}
```

**Result:** Valid trace objects are returned.

3. Confirm the block contains transactions using the explorer link above.

---

**Expected behavior**

`trace_filter` should return all traces for a block when querying a single-block range (`fromBlock == toBlock`). This behavior worked prior to the upgrade and matches the expected semantics of the method.

---

**Environment Information:**

- Chain: Optimism Mainnet
- Tracing Backend: op-reth
- Previous version (working): v1.8.3
- Current version (regression): v1.9.3
- Relevant upstream change:
- “Fix blocking task issue with larger block ranges in trace_filter (#19491)”

---

**Configurations:**

Default op-reth configuration. No special flags related to tracing.

---

**Logs:**

No node errors. The RPC call completes successfully but returns an empty array when it should contain trace data.

---

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the trace_filter requests for block 0x89A5645 and compare the tracing path across op-reth v1.8.3 and v1.9.3. Investigate the trace_filter RPC handling and the referenced upstream change; done means a single-block range returns the block's traces without regressing larger ranges.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
api, backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.