Live holes: a pending attribute inside a Loading boundary writes data-lha twice, and the element's later attr updates are dropped #4032

On next (4937f0a), an element inside a <Loading> whose attribute reads a pending value is rendered with two data-lha addresses:

<template id="01"><ul data-lha="1" data-lha="0" data-l="r:0"><li>x</li></ul></template>

Only lha:1 is bound. The stale data-lha="0" is also copied into every later attr op for that element:

type:"attr", key:"1", attrs:" data-lha=\"0\" data-l=\"r:1\""

What breaks

• First paint is fine. HTML parsers keep the first duplicate attribute, data-lha="1", which is the bound one.
• Attr updates stop after the first. In jsdom, the first op (key "1") applies and its attr text rewrites the element to data-lha="0". The next op for key "1" finds no element, returns applied: false ("pending; later flushes retry") and never lands. The attribute is stuck at its second value.
• The markup is also invalid HTML (a duplicate-attribute parse error), though browsers recover.

Minimal repro

This uses the same imports and collect() helper as packages/web/test/server/document-live-holes.spec.tsx:

const S = () => {
  const ready = createMemo(async () => (await wait(5), "r"));
  const tick = createMemo(async function* () { yield 0; await wait(20); yield 1; });
  const label = createMemo(() => ready() + ":" + tick());
  return <Loading fallback={<span>FB</span>}><ul data-l={label()}><li>x</li></ul></Loading>;
};
const html = await collect(() => (frameTransformDirectResult(S, { id: "r/H3" }) as any)({}));

The existing case in that spec, <ul data-ready={String(ready())}> inside <Loading> (around line 310), already produces <ul data-lha="1" data-lha="0" data-ready="true">. Its assertions don't look at the address.

Which variants duplicate

Re-evaluation sweeps never mint an address (live.sweeping gates it), so a sweep never duplicates.

Cause

Traced in the code and matched by the test output:

1. ssr() calls captureStart() (packages/web/src/server.ts, around line 4176). It mints an id, splices data-lha="N" in right after the tag name, and sets cap.base to everything after the splice.
2. When that in-tag hole escalates (NotReady), the code sets cap = null but leaves the spliced text in the template segment. That id is orphaned.
3. The <Loading> resume calls ctx.ssr(pending.t, ...pending.h) (packages/solid/src/server/hydration.ts:671; the same pattern is around signals.ts:3635) on the segment that still holds the orphan. The tag is still open there, so captureStart() mints again at the same offset. The new id goes first and the old one is pushed to the right.
4. The new capture's prefix now contains the stale data-lha="0", so cap.base and every attr text rebuilt by a sweep carry it.
5. On the client, #applyAttrs (packages/web/frames/src/frame-client.ts, around line 2198) skips data-lha only in its removal loop. Its set loop applies the data-lha="0" from the op text, which moves the element off its bound address.

Not confirmed: why the last variant in the table avoids the duplicate. It probably goes through <Loading>'s discovery loop, which re-renders the children from scratch, instead of through the resume path.

Possible fixes (untried)

• Remove the spliced address when a capture is dropped on escalation, at all three cap = null sites. This also stops orphan ids in the cases that don't duplicate.
• Or, in captureStart, replace an existing data-lha="…" at that offset instead of inserting a second one.
• As a defence, have the set loop in #applyAttrs skip data-lha, as the removal loop already does.