Commit Graph

2 Commits

Author SHA1 Message Date
d7363cc913 fix(rb-06): native capture worker is joined on stop
Some checks failed
check / cargo check (macos-latest) (push) Has been cancelled
check / cargo check (ubuntu-22.04) (push) Has been cancelled
check / cargo check (windows-latest) (push) Has been cancelled
check / svelte build + lint (push) Has been cancelled
The accumulator task was fire-and-forget — `tokio::spawn` without
retaining the JoinHandle. `stop_native_capture` sent a stop signal,
slept 50ms, and returned; the worker could still be running its
final flush and appending to `all_samples` when the next
`start_native_capture` cleared it. Rapid start→stop→start could
leak tail samples from one session into another.

Replace `NativeCaptureState.stop_tx` with `worker:
AsyncMutex<Option<CaptureWorker>>`, where CaptureWorker owns both
the stop sender and the spawned task's JoinHandle. New helper
`stop_worker(worker)` sends stop, drops the sender, and `.await`s
the join. Both the prior-worker tear-down in `start_native_capture`
and `stop_native_capture` itself go through the helper, so the
worker is always fully terminated before any downstream read or
next-session cleanup.

AsyncMutex (not std::sync::Mutex) because the stop path awaits
while holding the lock. Also drops the 50ms sleep from
stop_native_capture — the join is an exact barrier.

Two regression tests:
  - stop_worker_awaits_full_termination_no_writes_after_join:
    synthetic worker with an atomic counter and a flush marker.
    After stop_worker the flush must have run and no further
    writes may appear.
  - stop_worker_is_idempotent_on_a_worker_that_has_already_exited:
    tasks that stop themselves must still join cleanly.

A full cpal-backed start→stop→start integration test is not
feasible in Linux CI without an audio device. The component tests
cover the invariant the real flow depends on.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-22 10:36:34 +01:00
592b894790 docs(cr-2026-04-22): add release-blocker issue tracker at docs/issues/
Captures the 12 items from docs/code-review-2026-04-22.md that
must land before v0.1 ships. One markdown file per issue with:
severity, path:line, problem description, acceptance criteria,
fix scope, and dependency graph.

Split by severity:
- 3 CRITICAL: live-session race, migration atomicity, transcript-
  profile FK
- 9 MAJOR: monolith refactor, channel-fatality, capture worker
  join, runtime capabilities, macOS App Nap, decoder error prop,
  LLM prompt preflight, keystore thread-safety, hotkey device
  filter

README.md indexes them with a fix-order dependency graph and a
fish-shell script for bulk-converting to GitHub issues once `gh`
CLI is installed and authed. Deferred step by user decision —
markdown tracker is authoritative until then.
2026-04-22 09:46:08 +01:00