umputun / agterm / 34512581647

94%

push

github

fix(status): resolve sound names off the main actor (#580)

finishes #575. The merged half moved status-sound playback off the main actor; `NSSound(named:)` was still resolving there, so a sound file on slow storage blocked keystroke delivery even though playback no longer did. The reporter showed that with a WebDAV mount at three seconds.

cache misses now resolve on a worker queue. Cache hits and `default`/`beep` still answer without suspending, so validation never queues behind an in-flight `play()`.

`session.status` becomes async, which is the part worth reviewing. It previously ran straight through, so making it suspend opens a window that did not exist before. The target is bound before the await, so a slow lookup racing a UI selection change cannot redirect an implicit `active` target. `unknown sound` still outranks a missing target. Session liveness is revalidated on resume, and pane ownership and `wasBlocked` are read at the mutation with no suspension in between. A session that moves windows during resolution is now rejected rather than written to, which is a behavior change.

an invalid Settings blocked default still does not reject the status update, refused writes still play no sound, and Settings previews drop a stale selection instead of sounding after a newer choice.

lookups have their own queue, separate from playback. Serial rather than concurrent, and that one is a judgement call: parallel lookups would let a slow blocked default overlap a later command's first lookup, which is a real if narrow benefit, but `NSSound(named:)` reads a shared registry with no documented concurrency guarantee and this app has never called it concurrently. The unverified assumption looked like the worse bet.

one limitation stays, and it is inherent rather than an oversight. Answering `unknown sound` in the response means the handler awaits a cold lookup, and the accept loop is inline, so that lookup still occupies it. Removing that would mean giving u... (continued)

3 of 3 new or added lines in 1 file covered. (100.0%)

10511 of 11322 relevant lines covered (92.84%)

3604104.86 hits per line