Jake
813f024cdb
Phase B.8 audit of commits65abfa2(Obs-3, span propagation across spawn boundaries),8becb1a(audit-trail empty commit for Obs-4/5 absorbed intoafbd33d), andd1391b3(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>
47 lines
2.0 KiB
TOML
47 lines
2.0 KiB
TOML
[package]
|
|
name = "lumotia-storage"
|
|
version = "0.1.0"
|
|
edition = "2021"
|
|
description = "SQLite persistence, BM25 search, and file storage for Lumotia"
|
|
|
|
[dependencies]
|
|
lumotia-core = { path = "../core" }
|
|
|
|
# SQLite with compile-time checked queries
|
|
# default-features = false strips sqlx's `any`, `macros`, `migrate`, `json` —
|
|
# none of which this crate uses (it calls sqlx::query() / query_scalar()
|
|
# directly and runs its own migration machinery). Cuts ~40% of sqlx's
|
|
# compile graph, most visibly on Windows MSVC where each proc-macro crate
|
|
# (which `macros` pulls in) becomes a slow .dll link.
|
|
sqlx = { version = "0.8", default-features = false, features = ["runtime-tokio", "sqlite"] }
|
|
|
|
# Async runtime
|
|
tokio = { version = "1", features = ["rt", "sync", "macros"] }
|
|
|
|
# Serialisation (DailyCompletionCount exposed to frontend via Tauri commands)
|
|
serde = { version = "1", features = ["derive"] }
|
|
|
|
# Structured logging via `tracing` so storage events bridge into the
|
|
# subscriber installed by src-tauri/src/lib.rs::install_subscriber and
|
|
# land in both stderr and the rolling lumotia.log forensic stream. The
|
|
# storage crate was on the `log` crate up to Phase B.8; without a
|
|
# log→tracing bridge (e.g. tracing-log::LogTracer) those events
|
|
# vanished even though the EnvFilter directive `lumotia_storage=info`
|
|
# advertised them as visible.
|
|
tracing = "0.1"
|
|
|
|
# Structured error derivation for lumotia_storage::Error.
|
|
thiserror = "1"
|
|
|
|
# UUIDs for profile + profile_terms ids (v7 random).
|
|
uuid = { version = "1", features = ["v4"] }
|
|
|
|
[dev-dependencies]
|
|
# Real-file tempdirs for integration tests that need an on-disk DB (the
|
|
# in-memory `sqlite::memory:` connection in src/database.rs unit tests
|
|
# doesn't cover the rename-then-reopen path the rebrand migration exercises).
|
|
tempfile = "3"
|
|
# `rt-multi-thread` is required for the `#[tokio::test(flavor = "multi_thread")]`
|
|
# variants that drive blocking lumotia_core::paths migrations from async tests.
|
|
tokio = { version = "1", features = ["rt", "rt-multi-thread", "sync", "macros"] }
|