Jake 813f024cdb agent: lumotia — Phase B.8 bridge storage events into tracing subscriber ...

Phase B.8 audit of commits 65abfa2 (Obs-3, span propagation across
spawn boundaries), 8becb1a (audit-trail empty commit for Obs-4/5
absorbed into afbd33d), and d1391b3 (Obs-1/2, drop lumotia_live literal
target). Existing coverage:
  * commands::live::tests::no_lumotia_live_literal_target_in_live_rs
    pins Obs-1/2 — no literal lumotia_live target survives.
  * src-tauri/tests/tracing_appender_smoke.rs::init_tracing_creates_log_file
    pins Obs-4/5 — install_subscriber writes to a rolling lumotia.log.
  * Obs-3 (span propagation) is not directly tested. Verifying that
    `tokio::spawn` / `thread::spawn` children carry the parent span would
    require custom subscriber infrastructure; the commit message
    acknowledges the 4 instrumented sites as canonical correlation
    points + "everything else fans out from them" + "Storage/audio/
    hotkey/MCP crates left uninstrumented in this commit — future
    sweep". Honour the SAFETY-style annotation; do not chase a synthetic
    subscriber test.

One real residual found.

DEFAULT_STDERR_FILTER and DEFAULT_FILE_FILTER in src-tauri/src/lib.rs
both list `lumotia_storage=info` (stderr) / `lumotia_storage=debug`
(file). Operator intent: storage events surface in stderr AND in the
rolling lumotia.log forensic stream that diagnostic-report bundles
attach. The reality: every storage event vanishes.

The storage crate uses `log` crate macros (log::warn! / log::info!),
not tracing. src-tauri/src/lib.rs installs a tracing subscriber but
does NOT install a `tracing-log::LogTracer` bridge, so log-crate events
never reach any tracing layer. There is no other log subscriber wired
either, so the events are silently dropped.

Concrete signals missing from diagnostic reports:
  * Migration progress (info, lines 603 + 639 in migrations.rs) —
    fires on every schema bump on every first-run after upgrade. Used
    to confirm "did the user's migration succeed?".
  * Audio-cleanup warnings (warn) from delete_transcript (database.rs
    line 369) and purge_deleted_transcripts (line 434) — the two
    log lines Rev-3 specifically added so a forensic report could
    confirm whether disk cleanup completed cleanly.

Same forensic blindness Obs-4/5 fixed for the rest of the codebase,
just for the storage subset.

Fix:
  * crates/storage/Cargo.toml: replace `log = "0.4"` with
    `tracing = "0.1"`. Every other crate in the workspace already uses
    `tracing = "0.1"`; storage was the outlier.
  * Replace the 4 `log::*!(target: "lumotia_storage", …)` calls with
    `tracing::*!(target: "lumotia_storage", …)`. Targets unchanged.
  * Reformat the two migration log lines as structured tracing events
    (version + description fields rather than printf-style positional
    interpolation) so they're filterable by EnvFilter directives and
    machine-readable in the forensic stream.

No behaviour change to storage call semantics. Pure logging-pipeline
rewire.

Verification:
  * cargo test -p lumotia-storage --lib
      → 70/70 pass (unchanged — none of the tests depended on the log
      crate).
  * cargo fmt --check → clean.
  * cargo clippy --workspace --all-targets -- -D warnings → clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-14 19:48:13 +01:00

2.0 KiB

Raw Blame History

View Raw