POST Fusaka sync issues 1.9.3 (node stuck)

[justefg]

Describe the bug

Node stopped syncing after Fusaka upgrade. Not much useful stuff in the logs, just an awful lot of errors like:

02. This can be ignored if the node has recently restarted, restored from a snapshot or is still syncing."}}
execution-1  | {"timestamp":"2025-12-03T23:22:33.323525Z","level":"ERROR","fields":{"message":"could not process Flashblock","error":"Failed to extract header for canonical block number 39007403. This can be ignored if the node has recently restarted, restored from a snapshot or is still syncing."}}
execution-1  | {"timestamp":"2025-12-03T23:22:35.357532Z","level":"ERROR","fields":{"message":"could not process Flashblock","error":"Failed to extract header for canonical block number 39007404. This can be ignored if the node has recently restarted, restored from a snapshot or is still syncing."}}
execution-1  | {"timestamp":"2025-12-03T23:22:37.352710Z","level":"ERROR","fields":{"message":"could not process Flashblock","error":"Failed to extract header for canonical block number 39007405. This can be ignored if the node has recently restarted, restored from a snapshot or is still syncing."}}
execution-1  | {"timestamp":"2025-12-03T23:22:39.403873Z","level":"ERROR","fields":{"message":"could not process Flashblock","error":"Failed to extract header for canonical block number 39007406. This can be ignored if the node has recently restarted, restored from a snapshot or is still syncing."}}
execution-1  | {"timestamp":"2025-12-03T23:22:41.366547Z","level":"ERROR","fields":{"message":"could not process Flashblock","error":"Failed to extract header for canonical block number 39007407. This can be ignored if the node has recently restarted, restored from a snapshot or is still syncing."}}

Node version

curl -s -X POST http://127.0.0.1:8545   -H "Content-Type: application/json"   --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":1}'
{"jsonrpc":"2.0","id":1,"result":"reth/v1.9.3-27a8c0f/x86_64-unknown-linux-gnu/base/v0.2.1"}

Steps to reproduce

I just upgraded to fusaka and noticed my node is stuck. Worked alright a few days ago.

Node logs

execution-1  | {"timestamp":"2025-12-04T00:17:10.013266Z","level":"WARN","fields":{"message":"Post-merge network, but never seen beacon client. Please launch one to follow the chain!"}}

Platform(s)

No response

Container Type

Docker

What version/commit are you on?

Base Reth Node Version: 1.9.3-dev
Commit SHA: 27a8c0f
Build Timestamp: 2025-12-03T22:24:19.727657864Z
Build Features: jemalloc,otlp
Build Profile: maxperf

What database version are you on?

Not sure

root@2cbe7ec525bd:/app# ./base-reth-node db version
2025-12-03T23:41:41.433129Z  INFO Initialized tracing, debug log directory: /root/.cache/reth/logs/optimism

thread 'main' panicked at crates/node/src/main.rs:197:10:
called `Result::unwrap()` on an `Err` value: Datadir does not exist: "/root/.local/share/reth/optimism"

Location:
    /usr/local/cargo/git/checkouts/reth-e231042ee7db3fb7/27a8c0f/crates/cli/commands/src/db/mod.rs:79:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Which chain / network are you on?

base

What type of node are you running?

Full via --full flag

What prune config do you use, if any?

Default i think

[prune]
block_interval = 5

[prune.segments]
sender_recovery = "full"

[prune.segments.receipts]
distance = 10064

[prune.segments.account_history]
distance = 10064

[prune.segments.storage_history]
distance = 10064

[prune.segments.bodies_history]
before = 0

[prune.segments.merkle_changesets]
distance = 10064

If you've built Reth from source, provide the full command you used

No response

Code of Conduct

• I agree to follow the Code of Conduct

[iowar]

I encountered a similar issue, but in my case it happened on mainnet.. the node got stuck, likely due to a reorg.. so I unwound the DB to a block before the Fusaka upgrade and restarted reth, and the issue was resolved.. It might also be helpful to disable pruning until the node fully syncs