Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

クローズ
  • 何か問題がありますか？
#4,032 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
backend, frontend

調査の方向性

Start with captureStart() in packages/web/src/server.ts (around line 4176) and the three cap = null escalation sites, then the <Loading> resume call ctx.ssr(pending.t, ...pending.h) in packages/solid/src/server/hydration.ts (line 671). Reproduce with the spec packages/web/test/server/document-live-holes.spec.tsx, checking that the rendered data-lha attributes contain one address. Done means a pending attribute inside <Loading> renders a single data-lha, and later attr ops for that element keep the bound address.

索引モデルが issue の本文から書いたものです。

説明

bug

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

Case Result
Pending attr inside <Loading> data-lha="1" data-lha="0"
Pending attrs on both <ul> and <li> Both duplicated (2,0 and 3,1)
Pending attr in a component inside .map inside <Loading> 2,0
Waterfall (attr reads a memo that reads a pending memo) 1,0
Attr reads an iterable whose first yield is delayed Duplicated, and the stale address is in the op
Resolved attr inside <Loading> with a pending sibling text Single 0
Pending attr with no <Loading> Single 0
Sync attr then pending attr on the same element Single 0
Pending attr plus an iterable attr with a sync first yield, same element Single, clean ops

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.
主要言語
TypeScript
スター
36.1k
フォーク
1.1k
平均マージ
11時間 32分
マージ済み PR（30日）
356

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

solidjs/solid のほかの issue

solidjs/solid の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。