User Operations v1.4.3 leaves past RPC completion status false

[DenisCarriere]

Problem

The deployed ghcr.io/blockscout/user-ops-indexer:v1.4.3 remains healthy and live, but both entrypoint generations keep past_rpc_logs_indexing_finished=false. As a result, the aggregate finished_past_indexing flag remains false indefinitely and Stats v2.17.0 leaves User Operations-dependent charts in WAITING_FOR_STARTING_CONDITION.

Production evidence

Observed on Robinhood Blockscout after the one-time history pass completed:

{
  "finished_past_indexing": false,
  "v06": {
    "enabled": true,
    "live": true,
    "past_db_logs_indexing_finished": true,
    "past_rpc_logs_indexing_finished": false
  },
  "v07_v08": {
    "enabled": true,
    "live": true,
    "past_db_logs_indexing_finished": true,
    "past_rpc_logs_indexing_finished": false
  }
}

The production database contained 3,463,972 User Operations spanning block 411 through block 31,174,321, including 3,312,565 operations before block 30,000,000. Realtime indexing continued to add near-head rows. The configured past RPC range is the v1.4.3 default of 1,000 blocks, and logs show those ranges fetched successfully.

Source observation

In the v1.4.3 base_indexer, PastRpcLogsIndexingFinished is sent through a do_after hook chained to the finite RPC-refetch job stream. The status endpoint never observed that event in production even after both database streams had completed and realtime polling was current.

Current workaround

k8s-blockscout disables only Stats' native optional user_ops_past_indexing_finished start-condition check. User Operations historical and realtime indexing remain enabled. This moved all User Operations charts out of WAITING_FOR_STARTING_CONDITION; no chart classes remain blocked.

Exit criteria

• reproduce or disprove the missing PastRpcLogsIndexingFinished event on v1.4.3
• check whether a newer user-ops-indexer release fixes the status transition
• after an upgrade, verify both RPC flags become true and Stats can safely re-enable its wait condition
• remove the workaround only after live status and chart-start behavior are confirmed