Problem
When a managed Dolt server restarts, a client can briefly observe the server as reachable while a database probe reports "database not found". In gastownhall/beads#4449, the proposed beads-side workaround retries that DB-not-found probe with exponential backoff before falling through to bootstrap/init.
That restart tolerance is real and useful, but the retry belongs at the Dolt driver/storage boundary rather than in beads bootstrap code. Beads should not need storage-engine-specific sleep/retry loops to distinguish "database is genuinely absent" from "the server is still coming back after restart".
Why this should live in the driver
Beads can only infer this state indirectly from driver/server errors. If beads owns the retry loop, every caller has to duplicate driver-specific knowledge and tune backoff around managed-Dolt restart behavior.
There is also a concrete product cost to doing it in beads: in shared-server mode, a first-ever bootstrap for a new project on a machine whose shared server already hosts other project databases can eat the full backoff window before falling through to init. The submitted beads-side loop was 10s + 20s + 40s.
Requested behavior
Please consider one of these driver-level fixes:
- make transient restart/not-ready states distinguishable from a genuinely absent database;
- retry known transient DB-not-found probes inside the driver with bounded backoff; or
- expose an explicit driver option/capability so higher layers can request restart-tolerant open/probe behavior without hardcoding Dolt-server error handling.
Source context
This came from the Layer 2 portion of gastownhall/beads#4449. Beads plans to keep the Layer 1 URL guard from that PR, but route the managed-Dolt restart tolerance here rather than landing a beads-side storage workaround.
codex-gpt-5.5-high on behalf of matt wilkie
Problem
When a managed Dolt server restarts, a client can briefly observe the server as reachable while a database probe reports "database not found". In gastownhall/beads#4449, the proposed beads-side workaround retries that DB-not-found probe with exponential backoff before falling through to bootstrap/init.
That restart tolerance is real and useful, but the retry belongs at the Dolt driver/storage boundary rather than in beads bootstrap code. Beads should not need storage-engine-specific sleep/retry loops to distinguish "database is genuinely absent" from "the server is still coming back after restart".
Why this should live in the driver
Beads can only infer this state indirectly from driver/server errors. If beads owns the retry loop, every caller has to duplicate driver-specific knowledge and tune backoff around managed-Dolt restart behavior.
There is also a concrete product cost to doing it in beads: in shared-server mode, a first-ever bootstrap for a new project on a machine whose shared server already hosts other project databases can eat the full backoff window before falling through to init. The submitted beads-side loop was 10s + 20s + 40s.
Requested behavior
Please consider one of these driver-level fixes:
Source context
This came from the Layer 2 portion of gastownhall/beads#4449. Beads plans to keep the Layer 1 URL guard from that PR, but route the managed-Dolt restart tolerance here rather than landing a beads-side storage workaround.
codex-gpt-5.5-high on behalf of matt wilkie