fix(cli): pin HERMES_KANBAN_BOARD at chat boot to stop subprocess board drift#20094
fix(cli): pin HERMES_KANBAN_BOARD at chat boot to stop subprocess board drift#200940xDevNinja wants to merge 1 commit intoNousResearch:mainfrom
Conversation
…rd drift Without an explicit pin, in-process kanban tools and shelled-out `hermes kanban …` subprocesses resolve the active board on different paths: the env var when set, otherwise the global `<root>/kanban/current` file. When a concurrent session toggles the current-board pointer mid-turn, the same chat ends up routing tool calls to board A while its shell calls hit board B, surfacing as phantom "no such task" errors. Pin the resolved board into env once at `cmd_chat` boot when HERMES_KANBAN_BOARD isn't already set. Mirrors what the dispatcher does for spawned workers (kanban_db.py:2622-2623). Idempotent and a no-op when the env is already pinned by the caller. Closes NousResearch#20074
|
Merged via PR #20186 (commit f8a6db6). Your commit was cherry-picked onto current main with your authorship preserved in One small follow-up landed alongside: your test file used Thanks for the tight fix, clear repro, and the concrete suggestion on where to put the pin — made the salvage trivial. |
|
Appreciate the salvage and the fixture catch. |
What does this PR do?
In
cmd_chat, pin the resolved kanban board intoHERMES_KANBAN_BOARDonce at boot when the env var isn't already set. Without this, in-processkanban_*tools and shelled-outhermes kanban …subprocesses resolve the board on different paths — env-var pin if present, otherwise the global<root>/kanban/currentfile. A concurrenthermes kanban boards switchfrom another session can flip that file mid-turn, so the same chat ends up routing tool calls to board A while its shell calls hit board B, surfacing as phantom "no such task" errors when an orchestrator immediately tries toharness kanban show <id>afterkanban_create.This mirrors the behaviour the dispatcher already has for spawned workers (
hermes_cli/kanban_db.py:2622-2623) — pin the board into the child env so every code path resolves the same DB. Idempotent and a no-op when the caller has already exported the env (e.g. dispatcher-spawned worker, ad-hoc shell pin).Related Issue
Fixes #20074
Type of Change
Changes Made
hermes_cli/main.py: add_pin_kanban_board_env()helper and call it fromcmd_chatafter the existing env-flag block, before forking to TUI vs CLI.tests/hermes_cli/test_pin_kanban_board_env.py: cover the three branches — pin when unset, no-op when already set, swallowget_current_board()failures (boot must never crash because the kanban dir is missing or unreadable).How to Test
harness kanban boards switch space(Terminal 1)harness -p space-orchestrator chat(Terminal 1) — leave it sitting at the prompt.harness kanban boards switch harness-facet(Terminal 2, concurrent).kanban_createa task and then immediately shellharness kanban show <id>. Before the fix, the shell-out lands onharness-facetand reports "no such task". After the fix, both calls resolve tospacebecauseHERMES_KANBAN_BOARD=spacewas pinned at chat boot.pytest tests/hermes_cli/test_pin_kanban_board_env.py -v(3/3 pass).Checklist
Code
fix(scope):,feat(scope):, etc.)pytest tests/ -qand all tests pass (15 pre-existing failures in gateway/web_server/bedrock unrelated to this change; full hermes_cli suite green except those)Documentation & Housekeeping
docs/, docstrings) — N/A (helper docstring covers the rationale; no user-facing surface added)cli-config.yaml.exampleif I added/changed config keys — N/ACONTRIBUTING.mdorAGENTS.mdif I changed architecture or workflows — N/A