SurrealConnectionManager caches the Surreal connection and reuses it for
every operation. If the underlying WebSocket drops — e.g. the SurrealDB server
is restarted (docker compose up -d, a pod restart) — the manager has no way
to detect the transport-level disconnect: isConnected stays true, and
getConnection() keeps handing back the dead connection. Every subsequent
query then fails until the host process itself is restarted.
ConnectionRetryConfig / ExtendedConnectionConfig already exist in
src/connection/config.ts but are not wired into the connection manager.
Proposed
- Classify transport-level disconnect errors (WebSocket close / "no close
frame received or sent") distinctly from query errors.
- On a transport disconnect, redial under a per-connection lock so concurrent
failed callers coalesce onto a single reconnect, then retry the failed
operation once.
- Non-transport errors (bad SQL, schema violations, timeouts) still surface
immediately — no retry.
Deferred from v1.4.0: that release is scoped to v3 correctness fixes;
auto-reconnect is a separate resilience feature and is tracked here.
SurrealConnectionManagercaches theSurrealconnection and reuses it forevery operation. If the underlying WebSocket drops — e.g. the SurrealDB server
is restarted (
docker compose up -d, a pod restart) — the manager has no wayto detect the transport-level disconnect:
isConnectedstaystrue, andgetConnection()keeps handing back the dead connection. Every subsequentquery then fails until the host process itself is restarted.
ConnectionRetryConfig/ExtendedConnectionConfigalready exist insrc/connection/config.tsbut are not wired into the connection manager.Proposed
frame received or sent") distinctly from query errors.
failed callers coalesce onto a single reconnect, then retry the failed
operation once.
immediately — no retry.
Deferred from v1.4.0: that release is scoped to v3 correctness fixes;
auto-reconnect is a separate resilience feature and is tracked here.