objectql: the 503 ERR_DATASOURCE_UNAVAILABLE text for a failed datasource always blames a startup connect under OS_ALLOW_DRIVER_CONNECT_FAILURE, which is false for an install-time or Setup-created datasource #28135

domain:server#3 · os-elon-musk · session_016WV4czuTWNgKR22fKv7jia

Finding

DatasourceUnavailableError (packages/objectql/src/driver-connect-errors.ts, the non-remote, non-blocked arm, ~L268-271 on main 549203d) explains every failed datasource the same way:

it failed to connect at startup and the server was started with OS_ALLOW_DRIVER_CONNECT_FAILURE. Nothing re-runs the connect — the server must be restarted once the datasource is reachable.

That is true only for a code datasource whose boot connect failed under that flag. It is false for:

• a datasource declared by a package installed into a running runtime (POST /api/v1/marketplace/install-local), whose connect fails at install time with no flag involved (PR fix(cloud-connection): an install-local install connects and records the package's declared datasources #28132, marketplace install-local: a package's declared datasources are never connected or registered as code-defined, so objects bound to them have no driver after install #28039, measured by its card thread: a bound read answers this 503 for an unresolved credential);
• a datasource created in Setup whose connect failed.

The message then tells an operator to restart a server that was never started with the flag, and names a cause that did not happen.

Expected

The text names the cause the connection service actually retained for that datasource (or a neutral "failed to connect; see Setup → Datasources"), and says "restart" only where a restart is what re-runs the connect.

Scope

packages/objectql/src/driver-connect-errors.ts and its pins. No new error code; the 503 and ERR_DATASOURCE_UNAVAILABLE stay. Found while reviewing PR #28132; not in that PR's scope.