@bobfrankston/mailx-store 0.1.78 → 0.1.80

package/db.d.ts

@@ -25,6 +25,33 @@ export declare class MailxDB {
      *  DDL / migrations / backfills (the main writer already did, before this
      *  handle opened) and reject any write at the SQLite level. */
     readonly readOnly: boolean;
+    /** Set when a WRITER connection came back read-only anyway — the OS refused
+     *  read-write access at open and SQLite silently downgraded the handle (see
+     *  openWritable). Every write for the life of the process will throw. The
+     *  daemon reads this right after construction and raises a sticky fatal
+     *  banner; nothing else should ever swallow it. */
+    writeDenied: boolean;
+    /** Open the database read-WRITE and VERIFY that we actually got write
+     *  access.
+     *
+     *  SQLite silently downgrades to a read-only handle when the OS refuses the
+     *  read-write open (a transient sharing/permission denial — AV or backup
+     *  scan, a previous instance still exiting, resume-from-sleep). Nothing
+     *  throws at open: reads all work, and then EVERY write for the life of the
+     *  process fails with "attempt to write a readonly database". On 2026-08-02
+     *  that ran an entire boot as a zombie session — is_replied backfill,
+     *  membership collapse, addAccount for all four accounts, flags (★), sync:
+     *  all dead, surfaced only as a per-account banner ("outlook: attempt to
+     *  write a readonly database") that read like an account problem.
+     *
+     *  So: probe with a real write inside a transaction we then ROLL BACK, and
+     *  reopen with backoff while the verdict is read-only. It has to be an
+     *  actual page write — under WAL, `BEGIN IMMEDIATE` alone takes its lock in
+     *  the -shm wal-index and SUCCEEDS on a read-only database (measured), so a
+     *  lock-only probe reports healthy on exactly the handle we're hunting.
+     *  SQLITE_BUSY is the opposite verdict — it PROVES the handle is
+     *  write-capable and merely contended, so keep it. */
+    private openWritable;
     constructor(dbDir: string, opts?: {
         readOnly?: boolean;
         skipMigrations?: boolean;

package/db.js

@@ -426,17 +426,97 @@ const SCHEMA = `
     CREATE INDEX IF NOT EXISTS idx_message_folders_msg ON message_folders(message_row_id);
     CREATE INDEX IF NOT EXISTS idx_message_folders_folder_uid ON message_folders(folder_id, uid);
 `;
+/** Park the thread for `ms` without spinning. The DB is opened in a
+ *  constructor (no async available) and the write-access probe below needs to
+ *  wait out a transient lock; Atomics.wait is the only true sync sleep. */
+function sleepSync(ms) {
+    Atomics.wait(new Int32Array(new SharedArrayBuffer(4)), 0, 0, ms);
+}
 export class MailxDB {
     db;
     /** True for the DB read-worker's connection. Read-only handles never run
      *  DDL / migrations / backfills (the main writer already did, before this
      *  handle opened) and reject any write at the SQLite level. */
     readOnly;
+    /** Set when a WRITER connection came back read-only anyway — the OS refused
+     *  read-write access at open and SQLite silently downgraded the handle (see
+     *  openWritable). Every write for the life of the process will throw. The
+     *  daemon reads this right after construction and raises a sticky fatal
+     *  banner; nothing else should ever swallow it. */
+    writeDenied = false;
+    /** Open the database read-WRITE and VERIFY that we actually got write
+     *  access.
+     *
+     *  SQLite silently downgrades to a read-only handle when the OS refuses the
+     *  read-write open (a transient sharing/permission denial — AV or backup
+     *  scan, a previous instance still exiting, resume-from-sleep). Nothing
+     *  throws at open: reads all work, and then EVERY write for the life of the
+     *  process fails with "attempt to write a readonly database". On 2026-08-02
+     *  that ran an entire boot as a zombie session — is_replied backfill,
+     *  membership collapse, addAccount for all four accounts, flags (★), sync:
+     *  all dead, surfaced only as a per-account banner ("outlook: attempt to
+     *  write a readonly database") that read like an account problem.
+     *
+     *  So: probe with a real write inside a transaction we then ROLL BACK, and
+     *  reopen with backoff while the verdict is read-only. It has to be an
+     *  actual page write — under WAL, `BEGIN IMMEDIATE` alone takes its lock in
+     *  the -shm wal-index and SUCCEEDS on a read-only database (measured), so a
+     *  lock-only probe reports healthy on exactly the handle we're hunting.
+     *  SQLITE_BUSY is the opposite verdict — it PROVES the handle is
+     *  write-capable and merely contended, so keep it. */
+    openWritable(dbPath) {
+        const backoffMs = [0, 100, 300, 1000, 2000];
+        let lastErr = "";
+        for (let attempt = 0; attempt < backoffMs.length; attempt++) {
+            if (backoffMs[attempt])
+                sleepSync(backoffMs[attempt]);
+            const db = new DatabaseSync(dbPath);
+            try {
+                db.exec("BEGIN IMMEDIATE");
+                db.exec("CREATE TABLE _mailx_write_probe(x)");
+                db.exec("ROLLBACK"); // probe table never reaches the file
+                if (attempt > 0)
+                    console.log(`  [db] write access acquired on attempt ${attempt + 1}`);
+                return db;
+            }
+            catch (e) {
+                lastErr = e?.message || String(e);
+                if (!/readonly/i.test(lastErr)) {
+                    // Busy/locked — another writer holds the lock this instant.
+                    // That is a write-capable handle; take it.
+                    try {
+                        db.exec("ROLLBACK");
+                    }
+                    catch { /* no txn was opened */ }
+                    return db;
+                }
+                console.error(`  [db] opened READ-ONLY (attempt ${attempt + 1}/${backoffMs.length}): ${lastErr}`);
+                db.close();
+            }
+        }
+        // Out of retries. Return a handle anyway — reading mail beats no app at
+        // all — but flag it so the daemon can say so, loudly and stickily.
+        console.error(`  [db] FATAL: ${dbPath} is READ-ONLY after ${backoffMs.length} attempts — no change will be saved (${lastErr})`);
+        this.writeDenied = true;
+        return new DatabaseSync(dbPath);
+    }
     constructor(dbDir, opts = {}) {
         fs.mkdirSync(dbDir, { recursive: true });
         const dbPath = path.join(dbDir, "mailx.db");
         this.readOnly = !!opts.readOnly;
-        this.db = new DatabaseSync(dbPath);
+        this.db = this.readOnly ? new DatabaseSync(dbPath) : this.openWritable(dbPath);
+        if (this.writeDenied) {
+            // Asked for a writer, got a read-only handle (openWritable already
+            // shouted about it). Everything below — journal_mode, the schema,
+            // every migration and backfill — is a write, so running it would
+            // throw or bury the real message under a dozen derived errors.
+            // Set up as a reader and let the daemon surface the banner: the
+            // user can still READ mail while the app says, once and plainly,
+            // that nothing is being saved.
+            this.db.exec("PRAGMA foreign_keys = ON");
+            this.db.exec("PRAGMA busy_timeout = 5000");
+            return;
+        }
         if (opts.skipMigrations && !opts.readOnly) {
             // Write-capable connection that does NOT run schema/migrations —
             // used by the sync worker, which opens its own writer AFTER the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bobfrankston/mailx-store",
-  "version": "0.1.78",
+  "version": "0.1.80",
   "type": "module",
   "main": "index.js",
   "types": "index.d.ts",