hermes - ✅(Solved) Fix [Bug] Kanban: sqlite3.OperationalError: no such column: session_id after update [1 pull requests, 2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#28654Fetched 2026-05-20 04:02:47
View on GitHub
Comments
2
Participants
3
Timeline
7
Reactions
1
Author
Timeline (top)
labeled ×3commented ×2closed ×1cross-referenced ×1

Error Message

  1. Error appears constantly in logs

Fix Action

Fix / Workaround

Describe the bug After updating or doing a fresh install of Hermes Agent, the kanban dispatcher fails repeatedly with: sqlite3.OperationalError: no such column: session_id It happens every few seconds when the gateway is running.

Temporary workaround

rm -f ~/.hermes/kanban.db
hermes kanban init
Additional context
Seems to be a schema migration issue. New version expects session_id column but the existing database doesn't have it.

PR fix notes

PR #28781: fix(kanban): hoist all additive-column indexes out of SCHEMA_SQL (#28461)

Description (problem / solution / changelog)

Summary

Salvage of #28461 — fixes the Kanban DB legacy-migration crash reported in #28464 (and rediscovered in #28554, #28617, #28654, #28698) where connect() runs SCHEMA_SQL before _migrate_add_optional_columns(), so a legacy board missing any additive indexed column aborts schema init with OperationalError: no such column: <col> before the migration can add it.

The community filed six PRs for this bug (all on 2026-05-19). #28461 (itsreverence) was first and best-explained but only covered 2 of the 4 vulnerable indexes. #28754 (quocanh261997) extended coverage to 3 of the 4. This salvage combines the strengths of all the open PRs and closes the remaining gap.

What changed

Move every CREATE INDEX that depends on an additive column out of SCHEMA_SQL and create them after _migrate_add_optional_columns() adds the columns. All four additive-column indexes are now hoisted:

IndexAdditive columnIntroduced in
idx_tasks_session_idtasks.session_id#28447
idx_tasks_tenanttasks.tenant#16081
idx_tasks_idempotencytasks.idempotency_key#17805
idx_events_runtask_events.run_id#17805

Three of these were ticking landmines for any user whose board predated the column. idx_tasks_session_id was the one that bit users today because it's the most recent (#28447 merged the day before the bug reports flooded in), but the same migration trap applied to all four.

Beyond #28754's coverage:

  • idx_events_run: also hoisted out of SCHEMA_SQL and made unconditional in the migration. A legacy task_events table predating #17805 (no run_id) was still hitting the same SQLite trap that #28754 only addressed for tasks.
  • idx_tasks_idempotency: removed the redundant inner-conditional create (line ~1085) that was nested inside if "idempotency_key" not in cols:. Since the unconditional create lower in the function already runs CREATE INDEX IF NOT EXISTS, the inner one was dead code on fresh DBs once we removed the SCHEMA_SQL line.
  • Strengthened the regression test to cover all 4 indexes and to seed a pre-#17805 task_events shape that exercises the run_id migration path.
  • Added explicit rationale comments so the next contributor adding tasks.<new_col> doesn't re-introduce the trap.
  • Picked up an adjacent test fix from #28754: test_max_runtime_uses_current_run_start_after_retry now monkeypatch-es kb._pid_alive so it stops tripping tests/conftest.py's live-system guard on os.kill(<fake_pid>, 0). Pre-existing failure on origin/main, unrelated to the index ordering bug; carried in via the cherry-pick rather than split out separately.

Validation

Confirmed against origin/main:

origin/main reproduces against pre-#16081 fixture: no such column: session_id

Confirmed on this branch:

Scenario A: legacy DB missing all 4 additive columns      ✅
Scenario B: fresh DB                                       ✅
Scenario C: idempotency on already-migrated DB             ✅
Scenario D: partially-migrated DB (tenant+idempotency)     ✅

Test suite:

$ bash scripts/run_tests.sh tests/hermes_cli/test_kanban_db.py tests/hermes_cli/test_kanban_db_init.py
============================= 159 passed in 5.06s ==============================

Full tests/hermes_cli/ suite — 4888 passed, 13 pre-existing failures unrelated to kanban (gateway service / model picker / plugins) that match origin/main 1:1.

Lint diff: zero new ruff/ty issues vs origin/main (123 ty issues on changed files, identical on both base and head).

Credit

Original bug report and PR by @itsreverence (#28464 + #28461 — first to file, best write-up of the underlying ordering trap).

Cherry-picked commit on this branch authored by @quocanh261997 from #28754 (broadest open coverage — included tasks.tenant and tasks.idempotency_key).

Other PRs absorbed and to be closed as duplicates: #28741 (@stormhierta), #28562 (@kungunier), #28620 (@vanhci), #28602 (@verybigdog, DRAFT). All of them correctly diagnosed the bug; this salvage combines the broadest coverage with the most thorough comments and tests.

Closes #28464. Closes #28554. Closes #28617. Closes #28654. Closes #28698.

Changed files

  • hermes_cli/kanban_db.py (modified, +26/-18)
  • tests/hermes_cli/test_kanban_db.py (modified, +84/-1)
RAW_BUFFERClick to expand / collapse

Describe the bug After updating or doing a fresh install of Hermes Agent, the kanban dispatcher fails repeatedly with: sqlite3.OperationalError: no such column: session_id It happens every few seconds when the gateway is running.

Steps to reproduce

  1. Install or update Hermes Agent
  2. Run hermes gateway start
  3. Error appears constantly in logs

Environment

  • WSL2 Ubuntu 24.04
  • Running as root
  • hermes kanban init was executed

Temporary workaround

rm -f ~/.hermes/kanban.db
hermes kanban init
Additional context
Seems to be a schema migration issue. New version expects session_id column but the existing database doesn't have it.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - ✅(Solved) Fix [Bug] Kanban: sqlite3.OperationalError: no such column: session_id after update [1 pull requests, 2 comments, 3 participants]