[5ym]

#2764 のレビューで見つかったものを直します。

別の局を選ぶと、tune() がサーバの答えを待たずにデータ放送を閉じ、前の局 (lastService) を選んだ局に書き換えていました。サーバが選局を断ると (復号できない局の error。サーバは前の局を流したまま)、前の局を受信したままデータ放送だけが閉じていました。

• サーバの tuned に受けた局 (serviceId) を載せる (ライブだけ。追っかけには無い)
• 画面は待っていた局の tuned が届いたら閉じる (closingOnTune・tunedCloses)。続けて選び直したあとで前の指示の答えが遅れて届いても閉じない
• 答えを待つ間は前の局のデータ放送を出したまま、受信のリクエストだけ選局の指示より先にやめる (wantsData の switching)
• 断られたら (fail) 閉じずに受信のリクエストを戻す。エンジンはサーバが受けた局 (dataChannel) のもので、断られた局で作り直さない
• 追っかけに移ったら待つのをやめる。チューナーが取れないときは tuned が先に届くので、そのときは閉じる (サーバは前の局から抜けている)

テスト: data-receive.test.ts に決め方、E2E (20-live-tune) にライブの WebSocket の間に入って選局を断らせるものを足しました。E2E は直す前のコードで落ちることを確かめています。

🤖 Generated with Claude Code

https://claude.ai/code/session_01T8TqVbtN2Hp8wNmqBX8pzT

[claude]

Claude finished @5ym's task in 27s —— View job

---

レビュー結果

大きな不具合は見つかりませんでした。

不具合・競合

• tuned の処理は notice.serviceId === tuned.serviceId で絞っているので、続けて選び直したあとに前の指示の答えが遅れて届いても無視されます。2 から 1 (onAir と同じ局) へ戻した場合も、遅れて届いた 2 の答えは無視され、closing は null のままです。
• fail で closing を戻して syncData() を呼ぶ経路、追っかけへ移るときに closing = null にする経路、setData で closing = null にする経路は、それぞれ整合しています。
• 要確認: closesData と closingOnTune は serviceId だけで局を比べます。この比べ方は変更前から同じです。別のチャンネルに同じ serviceId の局があると、待っている局の答えと区別できません。実際に起きるかどうかは確認できていません。

セキュリティ

• 問題はありません。serviceId は数値で、サーバが受けた値をそのまま返しています。

テスト

• 「サーバが選局を断ったら…」のテストは closingOnTune を呼ぶだけです。fail が closing を戻す動作は確かめていないので、名前ほどのことは検証していません。この動作は E2E (20-live-tune) が受け持っているので、テスト名かコメントでそれが分かるとよいです。
• E2E で WebSocket の間に入って選局を断らせ、直す前のコードで落ちることを確認しているのは、回帰を防ぐ手段として十分です。

文章 (docs/writing.md)

• data-receive.ts の「約 2MB」は「約 2 MB」にしてください (インラインコメントを付けました)。
• 「待っている局を忘れる」(live-player.svelte.ts の fail 周辺のコメントと data-receive.ts の説明) は、コードが主語で人の動作を表す動詞です。「closing を null に戻す」のように、何をするかで書くほうが決まりに合います。

設計

• closingOnTune・tunedCloses・dataChannel に分けているので、既存の closesData と一貫していて、純粋関数としてテストできます。過剰な複雑さはありません。
  ・ ブランチ: fix/live-tune-data-close

[claude]

docs/writing.md の決まりでは、半角の英数字と単位の間に半角の空白を入れます。「約 2MB」は「約 2 MB」にしてください。

[claude]

Claude finished @5ym's task in 17s —— View job

---

レビュー結果

前回の指摘 (「約 2MB」→「約 2 MB」、「忘れる」の言い換え) は 2 つ目のコミット (fcea384) で直っています。新しく付ける指摘はありません。

不具合・競合

• tuned の処理は chase === null と notice.serviceId === tuned.serviceId で絞っています。続けて選び直したあとに前の指示の答えが遅れて届いても、closing と onAir は変わりません。
• fail、追っかけへ移る処理、setData はいずれも closing を null に戻します。fail では syncData() で受信のリクエストを戻します。
• 要確認: closesData・closingOnTune・tunedCloses は serviceId だけで局を比べます。この比べ方は変更前から同じです。別のチャンネルに同じ serviceId の局があると、待っている局の答えと区別できません。実際に起きるかどうかは確認していません。

セキュリティ

• 問題はありません。serviceId は数値で、サーバが受けた値をそのまま返しています。

テスト

• data-receive.test.ts は決め方 (closingOnTune・tunedCloses・wantsData の switching) を確かめています。テスト名とコメントで、fail が closing を戻す動作は E2E (20-live-tune) が受け持つと分かります。
• E2E で WebSocket の間に入って選局を断らせ、直す前のコードで落ちることを確認しているので、回帰を防ぐ手段として十分です。

文章

• docs/writing.md に反する箇所は見つかりませんでした。

設計

• onAir・closing・dataChannel に分けたことで、サーバが受けた局とリクエストした局の違いが明確です。既存の closesData とも一貫しています。
  ・ ブランチ: fix/live-tune-data-close