DP dispatches weaves against a dead HWND: 2,908 unbounded SDK log lines in 14s during a pane re-match

[dfattal]

Observed on a partner rig running Unity plugin v2.16.0. Non-fatal, low priority — filed so the dispatch path is on record, not because anything is broken in the field today.

Symptom

2,908 occurrences of Weaving is not possible because window handle is invalid in ~14 seconds — one per weave attempt, unbounded, at frame rate. The session recovered on its own and stopped cleanly.

Where it is not

Localised by grep across three repos before filing, so nobody repeats the search:

Repo	Result
displayxr-unity (Unity plugin)	no such string in native~/, Runtime/ or Editor/
displayxr-runtime	zero hits across src/ for either this or no handler for this window
displayxr-leia-plugin own source	not emitted here either

Both strings resolve inside the SR SDK, in *WeaverBaseImpl — modules/srDirectX/.../dxweaver_base_impl, srOpenGL/glweaver_base_impl, srVulkan/vulkanweaver_base_impl.

Why it lands here rather than upstream

Two candidate fixes:

(a) Gate the log inside the SR SDK. Correct for the flood as such, but upstream and slow.

(b) Stop calling the weaver with a dead HWND — the display processor's dispatch path. Better, because it avoids whatever work the SDK does before reaching the log line, not merely the line. If the DP validated the window before dispatching a weave, the SDK would never be asked and the flood would not exist.

(b) is the recommended fix, with (a) noted as the upstream option if the SDK is being touched anyway.

The evidence that localises it to the DP dispatch

The Unity plugin already parks its pane-follow the moment it detects the pane HWND has died (displayxr_set_pane_follow(NULL, 0,0,0,0)), so it stops handing over a dead handle immediately. The weave attempts continued for the full ~14 s regardless.

That is what rules out the consumer and points at the DP's dispatch path: the handle stopped being supplied and weaves kept being issued.

Suggested shape

First occurrence plus a count on recovery, rather than one line per attempt.

Worth noting this is the second instance of the same defect class in this component — issue-1257 found the zone-mask path emitting 6,429 WARN lines in six minutes. Two instances is a better argument for a logging convention here (rate-limit or first-plus-count for anything on a per-frame path) than either alone would be.

Reproduction caveat — please read before spending time

This was provoked by 24 scripted Game-view resizes during Play, leaving the editor layout in a state a saved layout never reaches. On re-entering Play the pane HWND from the previous match was gone, the plugin's glue detected it and began re-matching, and the flood filled that window.

That is a test artefact until someone hits it naturally. The partner has been asked not to spend rig time trying to force it. If it recurs on a plain Play → Stop → Play with no layout churn, that is a real report and will be attached here.

Related, and deliberately not conflated

The same session showed zero occurrences of the older WeaverBaseImpl: no handler for this window across ~10k lines and two full Play cycles. That message previously appeared as a 5,955-line burst that left the Unity editor's main window gone and the process spinning for five minutes, needing a lockfile cleanup to recover.

Recorded as "not observed, one sample" — not as fixed. Nobody has evidence of a change to the weaver's window-subclass lifetime, and a weaver is one-per-HWND requiring destroy-and-recreate rather than rebinding, so how the DP sequences that would be the place to look if it stays absent across more sessions. It is a different string and a different failure from the one above; a fix for one should not be credited with the other.

[dfattal]

The convention this issue argues for now exists in the vendor-facing docs — landed on displayxr-runtime main as 0896f23b7.

Worth knowing before anyone fixes this one, because it reframes what happened here.

The "never U_LOG_W on a per-frame path" rule did exist — but only in docs/reference/debug-logging.md and CLAUDE.md, both runtime-internal. No vendor-facing document stated it. And docs/reference/xrt_plugin_iface.md — the onboarding reference a plug-in author actually reads — showed a U_LOG_W example with no constraint attached:

void my_plugin_init(void) {
    U_LOG_W("plug-in version 1.0.0 init");
}

Correct, because init runs once. But nothing said so.

So a vendor following our own onboarding docs had no way to learn the rule. Two violations in one component inside a day is a documentation failure, not an author failure — and it only became visible because two instances surfaced independently and someone happened to know about both.

The iface reference now carries: which levels are for what (W/E for one-off init, error and lifecycle only; I and below for anything recurring, throttled), both real instances with their line counts as evidence that this floods rather than merely being untidy, and the first-occurrence-plus-count-on-recovery shape to reach for when a per-frame WARN feels tempting.

That does not change the fix recommended above — (b), validate the window before dispatching a weave, is still the better one here, because it avoids the work the SDK does before reaching the log line rather than just the line. But it means the logging half of this is now a documented convention with a citable home, rather than a preference argued from two anecdotes.