Failure semantics when a response ends before a streamed <template for> patch is closed

Summary

I have been testing the failure semantics of streamed Declarative Partial Updates when the response ends before a <template for> patch is closed.

In Chrome 150 stable (150.0.7871.47, no experimental flags), I observed two different incomplete-patch states:

• abrupt socket close: fallback content is removed, partial content may remain, markers remain, and the document stays loading;
• clean EOF before </template>: fallback content is removed, empty or partial content is committed, markers are removed, and the document reaches complete.

Results were verified in two independent setups: headless Chrome via the DevTools Protocol and a headed session on the same Chrome 150 build.

This may be consistent with the current design. I am not reporting this as a Chrome implementation bug, but as a failure-semantics / author-guidance question.

Repro:
https://github.com/federicobartoli/dpu-aborted-patch-repro

Chrome result:
https://github.com/federicobartoli/dpu-aborted-patch-repro/blob/main/CHROME_RESULT.md

Why this seems worth clarifying

The patching explainer says that when the template target is discovered, the content between the markers is removed, while the markers remain until the template is closed.

That creates an observable failure mode if the response ends before the closing </template> arrives.

Scenario	Result
Classic + abrupt socket close (/classic-abort)	Already-visible stable content remains intact; document remains loading.
Classic + clean EOF (/classic-clean)	Already-visible stable content remains intact; document reaches complete.
DPU + abrupt socket close immediately after template start (/abort-empty)	Fallback content is removed; range is empty; markers remain; document remains loading.
DPU + abrupt socket close during replacement content (/abort-partial)	Fallback content is removed; partial replacement content remains; markers remain; document remains loading.
DPU + clean EOF immediately after template start (/clean-empty)	Fallback content is removed; range is empty; markers are removed; document reaches complete.
DPU + clean EOF during replacement content (/clean-truncation)	Fallback content is removed; partial replacement content remains; markers are removed; document reaches complete.

The clean EOF case seems especially important because the document can become indistinguishable from a successful load at the platform level: readyState is complete, no page-level error is observed in this repro, and the markers that would allow a later re-patch are gone.

Recovery observation

After an abrupt socket close, the markers remain in the DOM, so an imperative rebuild, for example setHTMLUnsafe() on the host, is possible — though nothing signals when to attempt it.

After a clean EOF, the markers have been consumed, so no declarative re-patch target remains.

I am not claiming recovery is impossible in general. The point is that the two failure modes leave different recovery affordances, and neither exposes a patch-specific signal.

Relationship to existing discussions

I saw that whatwg/html#11818 is discussing error notification for patching failures.

This case seems different from a patch that fails to apply because of a target/reference-node problem: the patch starts applying successfully, existing content is removed, and then the response ends before the template is closed.

I also noticed #21 discussed patch status reflection/control. Is any patch-specific status or error surface still planned for this kind of incomplete streamed patch state?

Related:

• #31: template patches parsed through innerHTML / fragment parsing
• #37: paint holding
• #103: user-modified state inside replaced ranges

Questions

1. Is committing empty/partial patch content on clean EOF before </template> the intended behavior?
2. Should EOF force-closing an unfinished patch template be treated as an error rather than as a successful commit?
3. Is removal-at-target-discovery the intended final timing even when the template never closes normally?
4. Has delaying removal until the first replacement node arrives, or an atomic commit mode for some cases, been considered or rejected?
5. Should this be covered by the error-notification mechanism being discussed in whatwg/html#11818?
6. Should the explainer document the resulting DOM states and recovery implications?
7. Would WPT coverage for incomplete streamed patch responses be useful? I would be happy to help draft test cases.

Start with the linked dpu-aborted-patch-repro, especially CHROME_RESULT.md and the /abort-empty, /abort-partial, /clean-empty, and /clean-truncation cases. Read the patching explainer and compare the behavior with the error-notification discussion in whatwg/html#11818. Done means a maintainer decision on EOF semantics, recovery signaling, and whether explainer or WPT changes are needed.