SQLITE_CANTOPEN and SQLITE_IOERR are not truly transient

SQLITE_CANTOPEN typically indicates a permanent condition — the database file or its parent directory doesn't exist, or the process lacks permissions that won't fix themselves. Classifying it as transient means the gateway will silently continue running while unable to access its database, causing silent data-loss or reads returning stale data instead of crashing-fast.

SQLITE_IOERR is similarly dangerous: it's the parent code for disk-level I/O failures (SQLITE_IOERR_READ, SQLITE_IOERR_WRITE, SQLITE_IOERR_FSYNC, etc.) that can indicate disk corruption or hardware failure — not temporary contention. Swallowing it prevents the operator from knowing the database is in a bad state.

Consider narrowing the set to only codes that are genuinely retryable:

If SQLITE_CANTOPEN or SQLITE_IOERR must be handled at all, they should at minimum not be suppressed silently — they warrant a distinct code-path that either retries with backoff or shuts down with a clear error.

This is a comment left during a code review.
Path: src/infra/unhandled-rejections.ts
Line: 72-76

Comment:
**`SQLITE_CANTOPEN` and `SQLITE_IOERR` are not truly transient**

`SQLITE_CANTOPEN` typically indicates a permanent condition — the database file or its parent directory doesn't exist, or the process lacks permissions that won't fix themselves. Classifying it as transient means the gateway will silently continue running while unable to access its database, causing silent data-loss or reads returning stale data instead of crashing-fast.

`SQLITE_IOERR` is similarly dangerous: it's the parent code for disk-level I/O failures (`SQLITE_IOERR_READ`, `SQLITE_IOERR_WRITE`, `SQLITE_IOERR_FSYNC`, etc.) that can indicate disk corruption or hardware failure — not temporary contention. Swallowing it prevents the operator from knowing the database is in a bad state.

Consider narrowing the set to only codes that are genuinely retryable:

```suggestion
const TRANSIENT_SQLITE_CODES = new Set([
  "SQLITE_BUSY",
  "SQLITE_LOCKED",
]);
```

If `SQLITE_CANTOPEN` or `SQLITE_IOERR` must be handled at all, they should at minimum not be suppressed silently — they warrant a distinct code-path that either retries with backoff or shuts down with a clear error.

How can I resolve this? If you propose a fix, please make it concise.

Message check skips case normalization

Unlike isTransientNetworkError (line 186), which calls .toLowerCase().trim() before matching, the message here is used as-is and matched against uppercase literals. If a SQLite binding ever surfaces a lowercase variant (e.g. "sqlite_busy") or mixed-case message, these checks would silently miss it.

This is a comment left during a code review.
Path: src/infra/unhandled-rejections.ts
Line: 234-238

Comment:
**Message check skips case normalization**

Unlike `isTransientNetworkError` (line 186), which calls `.toLowerCase().trim()` before matching, the message here is used as-is and matched against uppercase literals. If a SQLite binding ever surfaces a lowercase variant (e.g. `"sqlite_busy"`) or mixed-case message, these checks would silently miss it.

```suggestion
    const message = typeof rawMessage === "string" ? rawMessage.toUpperCase() : "";
    if (message.includes("SQLITE_CANTOPEN") || message.includes("SQLITE_BUSY") ||
        message.includes("SQLITE_LOCKED") || message.includes("SQLITE_IOERR")) {
```

How can I resolve this? If you propose a fix, please make it concise.

Set busy_timeout before enabling WAL mode

Running PRAGMA journal_mode = WAL before PRAGMA busy_timeout = 5000 makes the first lock-sensitive statement execute with SQLite's default 0ms timeout, so a brief concurrent writer can cause immediate database is locked failures during DB open/reopen. This regresses the retry behavior described in the nearby comment ("retry instead of failing immediately"), and can make startup/reindexing flaky under normal multi-process contention.

Useful? React with 👍 / 👎.

Match transient SQLite errors using normalized messages

The new SQLite suppression path only matches uppercase substrings like SQLITE_BUSY/SQLITE_LOCKED, but common runtime forms in this codebase are normalized lowercase or plain text such as database is locked (for example, qmd-manager already checks those forms). As written, many transient SQLite lock rejections will not be recognized and still trigger process.exit(1), so the intended non-fatal handling is incomplete.

Useful? React with 👍 / 👎.