Priority Lanes Need Downstream Isolation
Priority lanes need downstream isolation
A priority lane is only real if the priority survives downstream.
Opening a second IPC connection, channel, queue, or task is useful when it prevents unrelated work from standing in line together. It is fake parallelism when both lanes immediately block on the same mutex, single actor, provider rate bucket, or long-running command.
The rule
Priority is an end-to-end property, not an ingress trick.
If warm work enters on a low-priority lane but then monopolises the actor that hot work needs, the hot path is still blocked. The bottleneck just moved.
What to check
- Does the warm lane call the same stateful actor as the hot lane?
- Are low-priority commands small enough to yield between hot commands?
- Does a shared lock cover network I/O or other
.awaitpoints? - Does the provider client have one global rate limit that both lanes can exhaust?
- Is the expensive part delegated to an isolated worker, or executed inside the hot actor?
This is where Don't Hold a Lock Across Await and Hot Path vs Warm Path meet. A long hold does not care that the request arrived through a "background" channel.
Spotuify example
In Spotuify, adding a warm IPC lane for queue warming helps only if the warm lane does not disturb playback controls. Lyrics, cover art, search indexing, and audio preload all have different downstream owners.
Some of those can run safely in background workers. Audio preload belongs to the player owner, because the player owns the real buffer and playback pipeline. See Preload Belongs to the Resource Owner.
The 2026-06-02 player hot-path fix made this concrete. The daemon now has a
dedicated player transport channel for play/pause/next/previous/seek/volume,
and the player actor checks that channel before ordinary player commands and
warm audio preloads. That is real priority, because it survives the hop into
the stateful actor that owns playback.
Mxr example
In Mxr, moving thread summaries off the main TUI interaction path requires two layers, not one.
The TUI uses a short-lived dedicated IPC connection for SummarizeThread so the normal TUI IPC worker can keep serving body fetches, search, and mutations. The daemon then routes SummarizeThread onto its bulk lane, because LLM calls can wait on inference for seconds.
The downstream check still matters. If the LLM provider is saturated, summaries may still queue behind other LLM work. That is acceptable only because the visible reader path is not blocked and stale responses are ignored when the user has moved to another thread.
The sync/mutation path added the provider version of the same rule. A manual
sync, background sync, and archive mutation now share a per-account provider
lane, because they all mutate or observe the same upstream truth. That lane is
account-scoped, not daemon-global, so one broken account does not block another.
See Provider Lanes Need Account Scope.