@bobfrankston/mailx-store 0.1.76 → 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
@@ -3704,8 +3784,26 @@ export class MailxDB {
         const LIKE_CC = ["m.cc_json"];
         const LIKE_SUBJ = ["m.subject"];
         const LIKE_ANY = ["m.subject", "m.from_name", "m.from_address"];
+        // `NOT <item>` — exclusion, usable ANYWHERE including as the leading
+        // (or only) token. FTS5's own NOT is strictly binary (`a NOT b`), so
+        // a leading NOT was an FTS5 syntax error that the dangling-operator
+        // trim "fixed" by dropping the NOT — silently searching FOR the term
+        // the user asked to exclude (Bob 2026-07-30). Instead of leaning on
+        // FTS5's operator, every `NOT x` pair is lifted OUT of the MATCH and
+        // applied as a SQL-side exclusion (`m.id NOT IN (SELECT rowid …
+        // MATCH x)`), which also negates qualifier tokens (`NOT from:…`,
+        // `NOT is:read`) uniformly. Uppercase only, same as AND/OR — a
+        // lowercase "not" stays an ordinary search term.
+        const notFrags = [];
+        let negateNext = false;
         for (let pi = 0; pi < parts.length; pi++) {
             const part = parts[pi];
+            if (part === "NOT") {
+                negateNext = true;
+                continue;
+            }
+            const wPre = extraWhere.length;
+            const fPre = frags.length;
             // A 1-2 char term next to a user-typed OR must be DROPPED, not
             // LIKE'd: LIKE clauses AND against the MATCH, so "ab OR sprinkler"
             // would intersect down to zero. Over-matching (just "sprinkler")
@@ -3826,12 +3924,14 @@ export class MailxDB {
                 extraWhere.push("LOWER(f.name) LIKE ?");
                 extraParams.push(`%${v.toLowerCase()}%`);
             }
-            else if (/^(AND|OR|NOT)$/.test(part)) {
+            else if (/^(AND|OR)$/.test(part)) {
                 // FTS5 boolean operators — pass through verbatim (must be uppercase).
                 // Without this branch, `hoddie AND git` got wildcarded into
                 // `hoddie* AND* git*`, which FTS5 reads as three required terms
                 // (one of them being any word starting with "AND") — so a real
                 // match like "Peter Hoddie" + "github" returned zero hits.
+                // (NOT is handled above as an exclusion prefix, not passed
+                // through — FTS5's binary-only NOT can't stand at the front.)
                 frags.push({ s: part, op: true });
             }
             else if (isTri) {
@@ -3893,6 +3993,20 @@ export class MailxDB {
                     }
                 }
             }
+            // Divert whatever this token contributed into the exclusion set.
+            // FTS frags move to notFrags (applied as a NOT IN subquery below);
+            // SQL-side qualifier clauses get wrapped in NOT(...) in place. An
+            // AND/OR right after NOT is nonsense input — the op frag stands
+            // and the stray NOT is dropped.
+            if (negateNext) {
+                if (!/^(AND|OR)$/.test(part)) {
+                    for (let w = wPre; w < extraWhere.length; w++)
+                        extraWhere[w] = `NOT (${extraWhere[w]})`;
+                    while (frags.length > fPre)
+                        notFrags.push(frags.pop().s);
+                }
+                negateNext = false;
+            }
         }
         // A term diverted to the LIKE fallback can strand a user-typed
         // operator at the edge of the MATCH string ("ab OR sprinkler" → the
@@ -3902,6 +4016,14 @@ export class MailxDB {
             frags.shift();
         while (frags.length && frags[frags.length - 1].op)
             frags.pop();
+        // NOT'd terms exclude via a subquery on the same FTS index: a message
+        // matching ANY excluded term is out. Works whether or not there are
+        // positive FTS terms — a pure `NOT foo` query takes the qualifier-only
+        // path below and returns everything except matches.
+        if (notFrags.length > 0) {
+            extraWhere.push("m.id NOT IN (SELECT rowid FROM messages_fts WHERE messages_fts MATCH ?)");
+            extraParams.push(notFrags.join(" OR "));
+        }
         // Join fragments. Two adjacent value fragments need an explicit `AND`
         // (implicit-AND after a `(...)` / `{...}:` group is an FTS5 syntax
         // error); a user operator fragment glues itself, so no insert around it.

package/package.json

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