[BUG] `bm schema validate <type>` prints its result then never exits — interpreter shutdown blocks on a lingering thread

[scarabone]

Bug Description

bm schema validate <note_type> never returns on the CLI. The server answers the underlying request in about 0.2 s (visible in basic-memory.log), and the CLI prints the Rich table header — then stalls indefinitely with the table half-drawn. The equivalent tool-path command, bm tool schema-validate --project main, validates every schema-covered note (499 notes) and returns JSON in 4 s, so this is specific to the bm schema validate command's output path, not to validation itself.

First seen on 0.22.1 (left running >5 min, never finished). Unchanged on 0.23.2.

Steps To Reproduce

1. Install version 0.23.2; a local project with a schemas/ folder holding a type: schema note (here OpenItem, 48 notes of type: open_item).
2. Run:

bm schema validate open_item --project main

3. Wait. Killed after 90 s in the run below; on 0.22.1 it was still running after 5 min.

Expected Behavior

The table renders and the command exits, in roughly the time the server takes to answer.

Actual Behavior

Output stops mid-table and the process never exits:

                          Schema Validation: open_item
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━┓
┃ Note                                            ┃ Status ┃ Warnings ┃ Errors ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━┓
(nothing further; killed at 90 s)

Server log for the same run — the work itself took 190 ms:

19:20:08.202 | INFO | basic_memory.mcp.tools.schema:schema_validate:306 - MCP tool call tool=schema_validate project=main note_type=open_item identifier=None
19:20:08.392 | INFO | basic_memory.mcp.tools.schema:schema_validate:320 - MCP tool response: tool=schema_validate project=main total=48 valid=48 warnings=19 errors=0

Control, same install, same project:

$ time bm tool schema-validate --project main   # all types, 499 notes
{ "total_notes": 499, "total_entities": 499, "valid_count": 499, "warning_count": 655, "error_count": 0, ... }
4 s

With --json the same command also never returns (killed at 45 s; output so far: { "note_type": "open_item", "total_notes": 48, "total_entities": 48, "valid_count": 48, "warning_count": 19, …).

Environment

• OS: macOS 27.0 (Apple Silicon)
• Python version: 3.12.13
• Basic Memory version: 0.23.2 (also 0.22.1)
• Installation method: uv tool install basic-memory==0.23.2 --prerelease=allow
• SQLite backend, local mode; run from an interactive zsh terminal (not piped)

Additional Context

The command's work is finished before the stall in both output modes — the full JSON document is printed (it ends with the closing }) and then the process never exits. A sample of the hung process (macOS, 3 s) shows why: the main thread is inside Python's interpreter-shutdown threading._shutdown join (__psynch_cvwait), waiting on one other thread that is still alive. So a non-daemon background thread started during the command is never stopped, and interpreter exit blocks on it forever.

sample of the hung process — main thread

2228 Thread_3795323   DispatchQueue_1: com.apple.main-thread  (serial)
+ 2228 start  (in dyld) + 6688  [0x19c647e88]
+   2228 Py_BytesMain  (in libpython3.12.dylib) + 36  [0x103ecc1ac]
+     2228 pymain_main  (in libpython3.12.dylib) + 456  [0x103ecc380]
+       2228 Py_RunMain  (in libpython3.12.dylib) + 1116  [0x103f042dc]
+         2228 pymain_run_file  (in libpython3.12.dylib) + 72  [0x103f1c508]
+           2228 pymain_run_file_obj  (in libpython3.12.dylib) + 164  [0x103f1c64c]
+             2228 _PyRun_AnyFileObject  (in libpython3.12.dylib) + 80  [0x103f1c860]
+               2228 _PyRun_SimpleFileObject  (in libpython3.12.dylib) + 464  [0x103f1cb4c]
+                 2228 _PyErr_PrintEx.llvm.2598405341583281504  (in libpython3.12.dylib) + 72  [0x103f5dd60]
+                   2228 Py_Exit  (in libpython3.12.dylib) + 20  [0x103f5e07c]
+                     2228 Py_FinalizeEx  (in libpython3.12.dylib) + 72  [0x103f04f90]
+                       2228 wait_for_thread_shutdown.llvm.346034759730459361  (in libpython3.12.dylib) + 104  [0x103f054d4]

the thread it is waiting on

2228 Thread_3795481
2228 thread_start  (in libsystem_pthread.dylib) + 8  [0x19ca18cec]
2228 _pthread_start  (in libsystem_pthread.dylib) + 136  [0x19ca1dd04]
2228 pythread_wrapper.llvm.11087623583669029680  (in libpython3.12.dylib) + 48  [0x10451ce04]
2228 thread_run  (in libpython3.12.dylib) + 148  [0x103ee3170]
2228 method_vectorcall.llvm.15953372922476583214  (in libpython3.12.dylib) + 356  [0x103fcced4]
2228 _PyEval_EvalFrameDefault  (in libpython3.12.dylib) + 175480  [0x103db00ac]
2228 method_vectorcall_VARARGS_KEYWORDS.llvm.10969388820976739405  (in libpython3.12.dylib) + 148  [0x103fd0dec]
2228 lock_PyThread_acquire_lock  (in libpython3.12.dylib) + 56  [0x104062ba0]
2228 acquire_timed  (in libpython3.12.dylib) + 344  [0x103e1c3d8]
2228 PyThread_acquire_lock_timed  (in libpython3.12.dylib) + 432  [0x103d6de74]
2228 _pthread_cond_wait  (in libsystem_pthread.dylib) + 980  [0x19ca1e1d4]
2228 __psynch_cvwait  (in libsystem_kernel.dylib) + 8  [0x19c9dc50c]

bm tool schema-validate is unaffected, so whatever starts that thread is specific to the bm schema validate command path (or is started there without the shutdown hook the tool path has).

[mikemikimike]

Implemented in PR #1342.

• Changed: The CLI analytics request now runs on a daemon thread, preventing interpreter shutdown from waiting indefinitely after schema validation completes.
• Tests: uv run --frozen pytest tests/cli/test_analytics.py tests/cli/test_cli_schema.py -q --no-cov (28 passed).
• Validation: Ruff check, Ruff format check, and git diff --check passed.