# Phase 1: Telegram Thread Leak Fix (P0) - Context

**Gathered:** 2026-03-20
**Status:** Ready for planning

<domain>
## Phase Boundary

Replace unbounded `threading.Thread` fire-and-forget in Telegram log sink with a bounded `ThreadPoolExecutor(max_workers=2)` to prevent thread exhaustion under high-volume logging (kintsugi batch repairs with SSL errors).

</domain>

<decisions>
## Implementation Decisions

### Claude's Discretion

All implementation choices are at Claude's discretion — pure infrastructure phase.

</decisions>

<code_context>

## Existing Code Insights

### Reusable Assets

- `python/opendeviationbar/logging.py:177-180` — current `threading.Thread(target=self._send, ...).start()` pattern
- `python/opendeviationbar/logging.py:182-189` — `_send()` static method with `send_telegram()` call
- `python/opendeviationbar/notify/telegram.py` — `send_telegram()` function (unchanged by this phase)

### Established Patterns

- Thread-local pattern already used in `repair_direct_parquet.py` for CH cache (same pattern being applied to kintsugi in Phase 2)
- Daemon threads used for fire-and-forget (`daemon=True` already set)
- `send_telegram()` timeout is currently 10s for all callers

### Integration Points

- `TelegramLogHandler.emit()` — only caller of `threading.Thread` for log sink
- Direct `send_telegram()` calls in sidecar.py, kintsugi.py — NOT affected by this change

</code_context>

<specifics>
## Specific Ideas

No specific requirements — infrastructure phase.

</specifics>

<deferred>
## Deferred Ideas

None — discussion stayed within phase scope.

</deferred>
