Description

Exclude background transaction indexing from the SyncProgress.Done() check so that eth.syncing returns false once block sync and state indexing are complete, without waiting for the full transaction index to be built.

Rationale

When running a node with --gcmode=archive, the flag handler forces TransactionHistory=0 (index entire chain). For a node bootstrapped from a snapshot (e.g. at block ~88M on BSC), the tx indexer must index ~86 million historical blocks — a process that can take days or weeks.

During this time, SyncProgress.Done() returns false because it requires TxIndexRemainingBlocks == 0, so eth.syncing never returns false even though block sync completed long ago and the node can fully serve current data.

Transaction indexing is a background maintenance task, not part of the initial chain sync. State indexing (StateIndexRemaining) is kept in the check because it is bounded by --history.state and finishes in reasonable time.

Note: upstream go-ethereum PR #32103 attempted to fix this by removing the archive mode TransactionHistory override in flags.go, but was rejected because transaction unindexing is very slow and causes significant I/O load. This fix takes a different approach by only changing the sync completion criteria.

Example

Before (archive node started from snapshot, block sync done):

> eth.syncing
{
  currentBlock: 88673649,
  highestBlock: 88634931,
  stateIndexRemaining: 0,
  txIndexFinishedBlocks: 2541198,
  txIndexRemainingBlocks: 86132452,
  ...
}

After:

> eth.syncing
false

Changes

Notable changes:

• Remove TxIndexRemainingBlocks == 0 from SyncProgress.Done() in interfaces.go
• StateIndexRemaining == 0 check is preserved — state indexing is bounded and completes in reasonable time
• txIndexFinishedBlocks and txIndexRemainingBlocks fields are still included in the eth_syncing response for monitoring
• Internal tx lookup readiness (BlockChain.TxIndexDone()) uses a separate TxIndexProgress.Done() method and is unaffected

Flow

eth.syncing (RPC call)
  → EthereumAPI.Syncing()                          [internal/ethapi/api.go]
    → api.b.SyncProgress()                          [eth/api_backend.go]
      → Downloader.Progress()                        (block sync: CurrentBlock, HighestBlock)
      → BlockChain.TxIndexProgress()                 (tx index: Indexed, Remaining)
      → BlockChain.StateIndexProgress()              (state index: Remaining)
    → progress.Done()                                [interfaces.go]  ← THE FIX
      ✓ CurrentBlock >= HighestBlock                 (block sync complete?)
      ✓ StateIndexRemaining == 0                     (state index complete?)
      ✗ TxIndexRemainingBlocks == 0                  (REMOVED — no longer blocks)
    → if Done(): return false                        (not syncing)
    → else: return { currentBlock, ..., txIndexRemainingBlocks, ... }

Flow with step

1. Line 158: api.b.SyncProgress(ctx) fetches the progress (which merges block sync + tx index + state index data)
2. Line 161: progress.Done() -- this calls our changed method in interfaces.go
3. Line 162: If Done() returns true --> returns false (meaning "not syncing")
4. Lines 165-184: If Done() returns false --> returns the full progress map (the object the issue reporter sees with all those fields like txIndexRemainingBlocks: 86132452)

-> this is use config in #3621

currentBlock: 88673649
highestBlock: 88634931
stateIndexRemaining: 0
txIndexRemainingBlocks: 86132452

Fixes #3621

Thanks for the PR — the problem is real and worth fixing, but I'd suggest a different approach.

Why not merge this:

Done() == true is widely interpreted as "the node is ready to serve complete data." Removing TxIndexRemainingBlocks == 0 means a node will report itself as synced while eth_getTransactionByHash for historical transactions silently returns null. Load balancers, health checks, and dApps doing traffic cutover on this signal will see incorrect results without any warning.

The root cause is in cmd/utils/flags.go:2214–2219, which unconditionally overrides TransactionHistory = 0 whenever --gcmode=archive is set — ignoring any explicit user configuration, whether via CLI flag or config file. That's what triggers an unexpected full-chain re-index.

Suggested fix in cmd/utils/flags.go:

if ctx.String(GCModeFlag.Name) == "archive" {
    if cfg.TransactionHistory == ethconfig.Defaults.TransactionHistory {
        cfg.TransactionHistory = 0
    }
}

@allformless I thought of that first, but since PR #32103 was closed upstream for doing something similar, I'm trying a different way.

For PR #32103 -> remove this cmd/utils/flags.go:2214–2219

@allformless I thought of that first, but since PR #32103 was closed upstream for doing something similar, I'm trying a different way.

For PR #32103 -> remove this cmd/utils/flags.go:2214–2219

if ctx.String(GCModeFlag.Name) == "archive" {
    if cfg.TransactionHistory == ethconfig.Defaults.TransactionHistory {
        cfg.TransactionHistory = 0
    }
}

a little different with PR32103

@allformless Sure I will follow your guide. Thank you. Will complete this PR soon.

@allformless Thank you. I just double-checked and you’re right—the instructions are spot on.

This will:
Changes the archive mode flag handler to only set TransactionHistory=0 if the user hasn't explicitly configured it.