# Expected Diagnosis: O11Y-2429368

## Root Cause

The `TiDBUnexpectedPanicInRecoverableGoroutine` alert was triggered by a recoverable goroutine panic with error `[executor:3024]Query execution was interrupted, maximum statement execution time exceeded`. This occurs when a user query exceeds `max_execution_time` and TiDB interrupts it via a panic in the recoverable goroutine handler. This is expected behavior, not a bug.

## Evidence Chain

1. **Loki logs**: Find the panic log entry containing `[executor:3024]` and `Query execution was interrupted, maximum statement execution time exceeded` within the alert time window
2. **Panic classification**: Match against known normal panic pattern — `executor:3024` is a timeout interrupt, which is expected TiDB behavior
3. **SlowQuery / TopSQL** (optional): Identify which query exceeded `max_execution_time` to provide context on why the timeout occurred

## Causality

User query exceeds `max_execution_time` setting -> TiDB interrupts query via recoverable goroutine panic (`[executor:3024]`) -> panic is recovered automatically -> alert `TiDBUnexpectedPanicInRecoverableGoroutine` fires -> no actual harm, query was terminated as designed

## Severity

Low — expected behavior, not a bug. The panic is by design for query timeout enforcement.

## Recommendations

1. **No action needed for the panic itself** — this is normal TiDB behavior for query timeout interruption
2. **Optionally investigate the timed-out query** — check SlowQuery logs for queries hitting `max_execution_time` to determine if the timeout setting needs adjustment or the query needs optimization
3. **Consider tuning alert rules** — if `[executor:3024]` panics are frequent and expected, consider adding an exclusion filter to the `TiDBUnexpectedPanicInRecoverableGoroutine` alert rule to reduce noise

## Scoring Rubric

> Checklist for regression testing. The Agent must satisfy these to pass.

- [ ] Find the panic log entry in Loki (containing `[executor:3024]` or `maximum statement execution time exceeded`)
- [ ] Identify the panic as a query timeout interrupt (not a bug)
- [ ] Classify the panic as expected/normal behavior
- [ ] NOT conclude the alert is a FAKE ALARM (the panic is real, just benign)
- [ ] Provide context on which query triggered the timeout (from SlowQuery or TopSQL)
- [ ] Recommend no fix needed for the panic itself, optionally suggest query/timeout tuning