xenia-rs/audit-runs/phase-absorber-review/absorber-inventory.md

Absorber inventory (Phase absorber-review, 2026-05-19)

The diff tool currently lands three absorbers that cross reading-error #23 (matching genuinely different guest behavior at the diff layer). Each is documented below — trigger, match heuristic, rationale, what is silenced.

The investigation goal is to determine whether any of them is hiding signal flow that would explain the AUDIT-049 wedge (tid=13 blocked on Event/Auto handle 0x12d0, sister wedges 0x1020/0x1040/0x10A8/0x10E4/0x12B8, sub_825070F0 worker spawner fires 0×).

A) Shared-global handle.create floating absorb (Phase C+18)

• File: diff_events.py::diff_one_tid, branch guarded by is_shared_global_handle_create + cross_tid_floating_sids.
• Trigger condition: at a kind mismatch, exactly one side has handle.create whose SID is in the cross-tid floating set.
• Match heuristic: the SID equals the deterministic shared_global_sid(pointer, object_type) recipe (FNV-1a over marker 0xC01AB005, pointer, object_type) OR appears across ≥2 distinct tids in either engine's stream (cross-tid usage heuristic).
• Rationale: process-global dispatcher objects (XAudio voice-volume semaphores, shared CSes, shared KEVENTs) get lazy-wrapped by whichever guest thread is the first toucher; that thread differs between cold runs. The SID recipe is scheduling-invariant so the diff can absorb the handle.create on the "wrong" tid.
• What's silenced: handle.create events for process-global dispatchers. Per-thread (alloc_handle_for/AddHandle) handle.create events are NOT silenced because their SID uses the per-(tid, idx) recipe.

B) Shared-global wait.begin floating absorb (Phase C+21)

• File: diff_events.py::diff_one_tid, branch guarded by is_shared_global_wait_begin.
• Trigger condition: at a kind mismatch, exactly one side has wait.begin whose handles_semantic_ids list includes at least one SID in the shared-global set.
• Match heuristic: any of the wait's handles matches the shared-global SID criterion above. For wait_type=all, ANY single shared-global handle is enough to classify the whole wait as floating (heuristic risk: a wait on one shared + multiple per-thread handles is fully absorbed).
• Rationale: contention on shared dispatchers is host-scheduler driven. One cold run may emit wait.begin (slow path) while another fast-paths past it without ever blocking. Reading-error #32.
• What's silenced: wait.begin events that touch shared-global dispatchers. The associated wait.end (which has its own field skips per SKIP_PAYLOAD_FIELDS_BY_KIND) still aligns positionally.

C) Nested-CS-cleanup absorber, Phase D D-extension (v1.5)

• File: diff_events.py::_try_absorb_nested_cs_cleanup, invoked from diff_one_tid.
• Trigger condition: kind mismatch where canary has import.call RtlEnterCriticalSection while ours has import.call RtlLeaveCriticalSection. Pattern is exact — NO other kind-mismatch shape engages this absorber.
• Match heuristic: walks canary forward consuming balanced [Enter-block(3), Leave-block(3)] pairs (each pair = 6 events: import.call, kernel.call, kernel.return for Enter; same triple for Leave). Cap _NESTED_CS_PAIR_CAP = 32. After each pair, checks whether canary's next event has the SAME kind AND payload name as ours's current event — first convergence wins (greedy).
• Rationale: the 104,607 cap is a producer-throughput divergence: canary's preemptive host-OS scheduling lets a peer tid insert more work items into a CS-protected registry/tree during a notification-event wait window than ours's cooperative scheduler does. Canary then iterates [E L] cleanups over those entries; ours has fewer entries and fast-Leaves. Per Phase D forensics, this is a real guest-behavior divergence, not jitter.
• What's silenced: contiguous [E L] blocks on canary's side at the specific Enter-vs-Leave mismatch site (~+439 events at the 104,607→105,046 advance per the D-extension memory).
• Stated caveat: this explicitly crosses reading-error #23. The band-aid was approved because the underlying root cause requires preempting the cooperative scheduler (invalidates 23 phases of digest stability; out of scope per H' plan).

Cross-references for wedge hunt

Per Phase W ground truth, the unsignaled handles at deadlock are:

0x00001020 Event/Manual waiters=1 signals=0 waits=1 wakes=0
0x00001040 Event/Auto   waiters=0 signals=0 waits=32 wakes=0
0x000010b0 Event/Auto   waiters=0 signals=0 waits=7 wakes=0
0x000010ec Event/Manual waiters=1 signals=0 waits=2 wakes=0
0x000012d0 Event/Auto   waiters=1 signals=0 waits=1 wakes=0  ← THE WEDGE
0x000012e4 Event/Auto   waiters=1 signals=0 waits=1 wakes=0

Per the dossier caveat (AUDIT-049 era ID 0x1288 → Phase W ID 0x12d0), handle ID is allocator-ordinal-dependent and does NOT match across engines. So we look up by canary's analog handles via the canary event stream — i.e. any Event/Auto whose tid+site equals canary's analog of ours's tid=13 sub_821CB030+0x1B0 worker create call. Per Phase W's table, canary tid=14/15 are the worker cluster (1.9M / 995K events). If an absorbed event on canary is a worker-cluster handle.create/wait.begin for an event-like object, that's wedge- relevant.