Missing CLI to diagnose "Latest filled block is not available

[Cripto5588]

Description:
Operators frequently encounter Latest filled block is not available when L2 loses L1 sync (#17263). Currently no CLI command exists to check L1→L2 sync status, forcing manual analysis across multiple Docker containers.

Problem:

text

• taiko-cli status: shows general node status
• No command shows: L1 head block vs L2 filled block gap
• Operators hunt logs across l1_node, l2_geth, l2_nmc (5+ containers)
  Reproduced in Codespace (real operator scenario):

text

Simulates real L1 RPC failure (empty/commented endpoint)

cd packages/taiko-client/internal/docker/nodes/

L1_ENDPOINT commented (real broken config)

docker compose up
What operators see:

text
l1_node | error: invalid value '' for '--timestamp ' (crash)
l2_geth | WARN Beacon client online, no consensus updates received
l2_geth | INFO Marked indexing initer as stalled
Current debugging = 30+ minutes:

text
docker ps # 5 containers
docker logs l1_node | tail # crash?
docker logs l2_geth | tail # sync?
docker logs l2_nmc | tail # tracker?

operator guesses which failed

Request: CLI command to show L1 sync status in one line (similar to taiko-cli status).

Screenshots attached:

docker ps (l1_node restarting)

docker logs l2_geth (sync stalled)

docker-compose.yml (L1_ENDPOINT missing)

[dantaik]

@Cripto5588 thanks for the detailed write-up 👋 — checking on status.

A CLI to diagnose L1→L2 sync gaps ("latest filled block is not available") would be a useful operator tool. Is this something you'd like to contribute, or are you proposing it for the team to pick up?

We'll keep it open if there's intent to implement; otherwise we can close it for now.

[Cripto5588]

@dantaik

Yes, I want to contribute with this CLI command.

I propose: taiko-cli sync-status

Example:
L1_head=18234567 | L2_filled=18234565 | Gap=2 | Synced=true

Before starting the implementation, could you clarify a few points for me?

Preferred location for the command (packages/taiko-client/cmd/?)
Should it reuse existing synchronization information from current services or expose a new API endpoint?

Are unit tests in Go sufficient, or would integration tests also be expected?

I will start/open the PR as soon as I understand your approach.

[Cripto5588]

Please provide your opinions on my proposed implementation:

1. Location: packages/taiko-client/cmd/syncstatus (new package similar to driver, proposer, etc.) or add to the main cmd if it's simple.

2. Functionality:
   Connect to L1 (via existing RPC flags).
   Get the L1 head (eth_blockNumber or headerByNumber).
   Get the last filled block from Taiko L2 (probably via an existing RPC method in the Taiko contract or the driver/indexer state).
   Calculate gap and status (Synchronized: gap <= limit — e.g., 5 blocks).
   Output and syntactic analysis:
   Enviar feedback