hermes - 💡(How to fix) Fix sqlite3.OperationalError: database is locked at first kanban dispatcher tick after every gateway startup

On every cold start, the gateway logs a sqlite3.OperationalError: database is locked error at the first kanban dispatcher tick (gateway/run.py, _kanban_dispatcher_watcher). The race is between _kanban_notifier_watcher and _kanban_dispatcher_watcher — both use an identical asyncio.sleep(5) startup delay, so their first ticks fire simultaneously. Each watcher calls _kb.connect(board=slug) (which auto-initialises the schema on first use via executescript + _migrate_add_optional_columns) and then immediately calls _kb.init_db(board=slug), which intentionally cache-busts _INITIALIZED_PATHS and re-runs the migration on a new connection. With two threads running this double-init pattern concurrently on the same DB file, the BEGIN IMMEDIATE in _migrate_add_optional_columns (~line 1032 of kanban_db.py) is issued by up to four connections simultaneously, and SQLite's write lock causes the error. The timeout=30 on sqlite3.connect() does not protect against this because it only applies to the connection call, not subsequently-issued SQL statements. The dispatcher self-recovers on the next tick, so the impact is cosmetic. Two potential fixes: (1) add a threading.Lock around the _INITIALIZED_PATHS check-and-set in connect() to serialise first-time init; (2) remove the redundant init_db() calls in both watchers, since connect() already handles schema init on first use.

Fix / Workaround

On every cold start, the gateway logs a sqlite3.OperationalError: database is locked error at the first kanban dispatcher tick (gateway/run.py, _kanban_dispatcher_watcher). The race is between _kanban_notifier_watcher and _kanban_dispatcher_watcher — both use an identical asyncio.sleep(5) startup delay, so their first ticks fire simultaneously. Each watcher calls _kb.connect(board=slug) (which auto-initialises the schema on first use via executescript + _migrate_add_optional_columns) and then immediately calls _kb.init_db(board=slug), which intentionally cache-busts _INITIALIZED_PATHS and re-runs the migration on a new connection. With two threads running this double-init pattern concurrently on the same DB file, the BEGIN IMMEDIATE in _migrate_add_optional_columns (~line 1032 of kanban_db.py) is issued by up to four connections simultaneously, and SQLite's write lock causes the error. The timeout=30 on sqlite3.connect() does not protect against this because it only applies to the connection call, not subsequently-issued SQL statements. The dispatcher self-recovers on the next tick, so the impact is cosmetic. Two potential fixes: (1) add a threading.Lock around the _INITIALIZED_PATHS check-and-set in connect() to serialise first-time init; (2) remove the redundant init_db() calls in both watchers, since connect() already handles schema init on first use.