[onewland]

Adds a ReplicationDelayByTable predefined system query to Snuba Admin. For every replicated table on the selected host it shows:

• absolute_delay from system.replicas
• the host's max_replica_delay_for_distributed_queries setting
• considered_stale: whether the delay is above that threshold, which means distributed queries skip this replica (unless every replica of the shard is stale and fallback_to_stale_replicas_for_distributed_queries is on)
• is_readonly

Host-level replication delay monitoring reports only the max across all tables. This query makes it easy to find which table is driving that number and whether reads are affected. For example, a table whose replication queues were deliberately stopped will show a steadily climbing delay.

Tested locally: the query passes is_query_using_only_system_tables and tests/admin/test_api.py::test_predefined_system_queries passes.

🤖 Generated with Claude Code

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 1711d71. Configure here.}

[cursor]

Incorrect stale replica threshold comparison

Low Severity

considered_stale flags a replica only when absolute_delay is strictly greater than max_delay. ClickHouse skips a replica when delay is greater than or equal to max_replica_delay_for_distributed_queries, so a replica sitting at the threshold is reported as not stale even though distributed queries skip it.

 

^{Reviewed by Cursor Bugbot for commit 1711d71. Configure here.}