Just a quick update for anyone using this approach:
The method described above (based on CLUSTER_STATEMENTS_SUMMARY and CLUSTER_STATEMENTS_SUMMARY_HISTORY) is unfortunately no longer reliable in real Forge workloads.
These system tables live only for a very short time and their contents are frequently evicted under load. In practice, long-running resolvers and multi-step SQL workflows often finish after the metadata has already been discarded, which makes the “last hour” analysis inconsistent or empty.
A more reliable replacement
I’ve replaced this mechanism in forge-sql-orm with a deterministic observability layer:
It provides:
- exact SQL digest logging (no dependency on TiDB memory windows)
- TopSlowest mode with stable per-resolver analytics
- optional EXPLAIN ANALYZE collection
- automatic OOM and Timeout post-mortem detection , without re-executing the failing query
- predictable behavior even for long invocations, pagination chains, joins, window functions, etc.
This gives a consistent and Forge-safe way to understand what actually happened inside a resolver — without relying on ephemeral TiDB metadata.
If anyone is still using the old CLUSTER_STATEMENTS_SUMMARY-based trigger, I highly recommend switching to the new observability system.