3.6 KiB
id, title, status, assignee, created_date, updated_date, labels, dependencies, priority
| id | title | status | assignee | created_date | updated_date | labels | dependencies | priority | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| TASK-256 | Fix texthooker page live websocket connect/send regression | Done |
|
2026-03-30 06:04 | 2026-03-30 06:12 |
|
medium |
Description
Investigate why the bundled texthooker page loads at the local HTTP endpoint but does not reliably connect to the configured websocket feed or receive/display live subtitle lines. Identify the regression in the SubMiner startup/bootstrap or vendored texthooker client path, restore live line delivery, and cover the fix with focused regression tests and any required docs updates.
Acceptance Criteria
- #1 Bundled texthooker connects to the intended websocket endpoint on launch using the configured/default SubMiner startup path.
- #2 Incoming subtitle or annotation websocket messages are accepted by the bundled texthooker and rendered as live lines.
- #3 Regression coverage fails before the fix and passes after the fix for the identified breakage.
- #4 Relevant docs/config notes are updated if user-facing behavior or troubleshooting guidance changes.
Implementation Plan
- Add a focused CLI regression test covering
--texthookerstartup when the runtime has a resolved websocket URL, proving the handler currently starts texthooker without that URL. - Extend CLI texthooker dependencies/runtime wiring so the handler can retrieve the resolved texthooker websocket URL from current config/runtime state.
- Update the CLI texthooker flow to pass the resolved websocket URL into texthooker startup instead of starting the HTTP server with only a port.
- Run focused tests for CLI command handling and texthooker bootstrap behavior; update task notes/final summary with the verified root cause and fix.
Implementation Notes
Root cause: the CLI --texthooker path started the HTTP texthooker server with only the port, so the served page never received bannou-texthooker-websocketUrl and fell back to the vendored default ws://localhost:6677. In environments where the regular websocket was skipped or the annotation websocket should have been used, the page stayed on Connecting... and never received lines.
Fix: added a shared resolveTexthookerWebsocketUrl(...) helper for websocket selection, reused it in both app-ready startup and CLI texthooker context wiring, and threaded the resolved websocket URL through handleCliCommand into Texthooker.start(...).
Verification: bun run typecheck; focused Bun tests for texthooker bootstrap, startup, CLI command handling, and CLI context wiring; browser-level repro against a throwaway source-backed texthooker server confirmed the page bootstraps ws://127.0.0.1:6678, connects successfully, and renders live sample lines (テスト一, テスト二).
Docs: no user-facing behavior change beyond restoring the intended existing behavior, so no docs update was required.
Final Summary
Restored texthooker live line delivery for the CLI/startup path that launched the page without a resolved websocket URL. Shared websocket URL resolution between app-ready startup and CLI texthooker context, forwarded that URL into Texthooker.start(...), added regression coverage for the CLI path, and verified both by focused tests and a browser-level throwaway server that connected on ws://127.0.0.1:6678 and rendered live sample lines.