Orchestrator teardown timeout (5 s) is too short, causing spurious teardown warnings on macOS #435

New Issue

2026-07-20T15:34:53-04:00

didericis-claude commented

2026-07-20 15:34:53 -04:00

Problem

When a macOS bot-bottle session closes, teardown_consolidated issues a DELETE /bottles/{id} against the orchestrator control plane. The request uses OrchestratorClient's hard-coded DEFAULT_TIMEOUT_SECONDS = 5.0, which is too short — on a slow or momentarily loaded host the request times out, raising an OrchestratorClientError:

bot-bottle: warning: macos-container teardown failed: OrchestratorClientError('DELETE /bottles/dd960bd3efaf5840: <urlopen error timed out>')

teardown() in launch.py catches the exception, logs the warning, revokes deploy keys (which succeeds), then re-raises — producing a full Python traceback even though the session otherwise completed cleanly.

The same code path exists in the docker and firecracker backends (backend/docker/consolidated_launch.py:149, backend/firecracker/consolidated_launch.py:99).

Fix

Make the teardown timeout configurable via a priority chain:

BOT_BOTTLE_ORCHESTRATOR_TEARDOWN_TIMEOUT_SECONDS env var
teardown_timeout_seconds key in a new orchestrator_config table in bot-bottle.db
Default of 30 s (raised from 5 s)

The new OrchestratorConfigStore (key/value table, same shared DB, same DbStore/TableMigrations pattern) stores the DB-level setting. resolve_teardown_timeout() implements the priority chain and is called at callback-registration time in each backend's launch.py.

Scope

New bot_bottle/orchestrator/config_store.py (OrchestratorConfigStore, resolve_teardown_timeout)
teardown_consolidated() in all three backends gains a timeout keyword arg
All three launch.py files pass timeout=resolve_teardown_timeout() to stack.callback

## Problem When a macOS bot-bottle session closes, `teardown_consolidated` issues a `DELETE /bottles/{id}` against the orchestrator control plane. The request uses `OrchestratorClient`'s hard-coded `DEFAULT_TIMEOUT_SECONDS = 5.0`, which is too short — on a slow or momentarily loaded host the request times out, raising an `OrchestratorClientError`: ``` bot-bottle: warning: macos-container teardown failed: OrchestratorClientError('DELETE /bottles/dd960bd3efaf5840: <urlopen error timed out>') ``` `teardown()` in `launch.py` catches the exception, logs the warning, revokes deploy keys (which succeeds), then re-raises — producing a full Python traceback even though the session otherwise completed cleanly. The same code path exists in the docker and firecracker backends (`backend/docker/consolidated_launch.py:149`, `backend/firecracker/consolidated_launch.py:99`). ## Fix Make the teardown timeout configurable via a priority chain: 1. `BOT_BOTTLE_ORCHESTRATOR_TEARDOWN_TIMEOUT_SECONDS` env var 2. `teardown_timeout_seconds` key in a new `orchestrator_config` table in `bot-bottle.db` 3. Default of **30 s** (raised from 5 s) The new `OrchestratorConfigStore` (key/value table, same shared DB, same `DbStore`/`TableMigrations` pattern) stores the DB-level setting. `resolve_teardown_timeout()` implements the priority chain and is called at callback-registration time in each backend's `launch.py`. ## Scope - New `bot_bottle/orchestrator/config_store.py` (`OrchestratorConfigStore`, `resolve_teardown_timeout`) - `teardown_consolidated()` in all three backends gains a `timeout` keyword arg - All three `launch.py` files pass `timeout=resolve_teardown_timeout()` to `stack.callback`

gitea-actions bot added the Status/Needs Triage label 2026-07-20 15:35:08 -04:00

didericis referenced this issue from a commit

2026-07-20 15:36:50 -04:00

fix: make orchestrator teardown timeout configurable (closes #435)

didericis-claude referenced a pull request that will close this issue

2026-07-20 15:36:59 -04:00

fix: make orchestrator teardown timeout configurable #436

didericis referenced this issue from a commit

2026-07-20 18:33:09 -04:00

fix: make orchestrator teardown timeout configurable (closes #435)

didericis added Kind/Enhancement

Priority