fn priority_pane_key(event: &Value) -> Option<String>Expand description
Extract a fairness key so a flood of PTY output from one pane can’t queue an unbounded number of frames ahead of a different pane’s own keystroke echo sitting in the same lane.
Reordering is scoped to blockfile events ONLY — that’s the one event
type a single pane can flood the shared lane with, and PTY bytes from
different panes are causally independent (only same-pane ordering
matters, which each key’s own FIFO group preserves). Every OTHER event
type on this lane (waveobj:update, waveobj:batchedupdates, the initial
config push, RPC replies) returns the same NON_PANE_EVENT_KEY and so
stays in ONE FIFO group, never reordered relative to each other.
This restriction is load-bearing, not a simplification: a waveobj:update
for object X and a LATER waveobj:batchedupdates that also touches X must
never be reordered relative to each other, but an unscoped batch has no
single object id to key on — an earlier version of this function keyed
updates by their individual oref/scope and left unscoped batches in
their own group, which let round-robin interleave [update, delete] into
[update, delete, update]-style reorderings; the frontend doesn’t
version-guard deletes, so a resurrected-then-redeleted object could render
as resurrected until reload. See the review discussion on the PR that
introduced this function.