fatxpool: `maintain()` stalls for 60+ seconds when parachain finality lags the best block

[manuelmauro]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Description of bug

Summary

In the fork-aware transaction pool, every NewBestBlock maintenance pass walks the entire header range from the last finalized block to the current best block, synchronously, on a tokio worker. On a parachain node whose relay-chain sync hasn't caught up yet (so parachain finality is stalled while the best head keeps advancing) this range is measured in millions of blocks and a single maintain() takes tens of seconds, blocking the import-notification pipeline and causing the node to appear desynced.

Reported from a Moonbeam user running moonbeamfoundation/moonbeam-tracing:v0.50.5 (polkadot-sdk stable2512), see moonbeam-foundation/moonbeam#3720.

Observed log (verbatim)

  2026-04-01 09:04:13 [🌗] maintain txs=(17, 0) a=2 i=0
      views=[(15045704, 14, 0), (15045556, 1, 16)]
      event=NewBestBlock { hash: 0xb265…33b8, tree_route: None }
      duration=60.365804416s
  2026-04-01 09:04:15 [Relaychain] ⚙️  Syncing 27.4 bps, target=#30611346,
      best: #26325851, finalized #26325504
  2026-04-01 09:04:15 [🌗] ⚙️  Preparing 0.0 bps, target=#15045714,
      best: #15045706, finalized #10781162

Parachain: best #15045706, finalized #10781162 → gap of ~4.26 M blocks. Relay chain is still syncing, so GRANDPA-driven parachain finality cannot advance. maintain duration is 60.37 s. One CPU thread pegged at
100%.

Steps to reproduce

No response

[bkchr]

CC @michalkucharczyk