fix: BusTui.connect() reconnect loop leak + ISSUES.md cleanup #19

[four-bytes-robby]

Closes #19

Changes

• src/bus-tui.ts: Add bus.close() in connect() catch block to prevent onclose → scheduleReconnect loop on dead instance
• ISSUES.md: Update lifecycle patterns table (Issues [P17b] Implement BusClient — server-side HTTP publisher #1/[P17b] Add type-safe message contracts and package exports #3 now marked ✅ done), remove outdated code example

---

Summary by cubic

Fixes a reconnect loop leak in BusTui.connect() by closing the bus when open() fails, preventing an onclose → scheduleReconnect loop on a dead instance. Updates ISSUES.md to reflect the current retry model (connect() throws on failure; initial discovery/retry lives in useServiceBus; scheduleReconnect() handles post-connect drops), marks Issues #1/#3 as done, and removes the outdated example.

^{Written for commit 031758c. Summary will update on new commits.}

Summary by CodeRabbit

• Bug Fixes

  • Fixed TUI bus connection failure handling by ensuring resources are released when an initial open attempt fails, preventing stuck infinite reconnection retry loops.

• Documentation

  • Updated TUI bus reconnection guidance and lifecycle patterns in the issues reference, including the recommended approach for reconnect/retry behavior.

[coderabbitai]

Caution

Review failed

The pull request is closed.

Recent review info

Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c0f9bf08-4d42-49f2-8605-da52eb9ec7c4

Commits

Reviewing files that changed from the base of the PR and between 39b5433 and 031758c.

Files selected for processing (1)

• ISSUES.md

---

Walkthrough

Walkthrough

Adds a single bus.close() call in the catch block of BusTui.connect() to prevent a leaked instance from entering the onclose -> scheduleReconnect retry loop when bus.open() fails. ISSUES.md is updated to reflect the current implementation and mark lifecycle pattern table entries as completed.

Changes

BusTui reconnect loop fix and documentation sync

Layer / File(s)	Summary
BusTui.connect() catch block closes instance on failure src/bus-tui.ts	The catch block in BusTui.connect() now calls bus.close() before re-throwing, stopping the onclose -> scheduleReconnect loop that would otherwise run on a partially constructed dead instance.
ISSUES.md reflects current implementation and marks entries done ISSUES.md	Issue #3 description is rewritten to describe the actual implementation: BusTui.connect() throws on failure and useServiceBus is the recommended TUI path. The lifecycle patterns table row for "TUI: reconnect with port re-discovery" is marked as completed.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related PRs

• four-bytes/four-opencode-plugin-lib#16: Modifies the same BusTui.connect() method's failure handling by removing the MemoryBus fallback, which is the prior change this PR builds upon with the bus.close() fix.
• four-bytes/four-opencode-plugin-lib#12: Changes scheduleReconnect to re-discover the port before retrying, directly related to the reconnect lifecycle that this PR prevents from leaking on failed connections.
• four-bytes/four-opencode-plugin-lib#14: Modifies BusTui.connect() failure behavior around bus.open() by removing the in-memory fallback, the same connection lifecycle path patched here.

Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main changes: fixing a reconnect loop leak in BusTui.connect() and cleaning up ISSUES.md documentation.
Linked Issues check	✅ Passed	All three coding-related objectives from issue #19 are addressed: bus.close() added in catch block to fix reconnect loop, ISSUES.md table updated to mark issues as done, and outdated code example removed.
Out of Scope Changes check	✅ Passed	All changes are directly aligned with issue #19 requirements: src/bus-tui.ts fix prevents reconnect loop leak, and ISSUES.md updates correct outdated documentation.

_{Tip: You can configure your own custom pre-merge checks in the settings.}

Finishing Touches

Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/19-reconnect-leak-docs-cleanup

Simplify code

• Create PR with simplified code
• Commit simplified code in branch fix/19-reconnect-leak-docs-cleanup

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@ISSUES.md`:
- Around line 94-99: Rewrite the paragraph in ISSUES.md (lines 94-99) to clarify
the current retry flow. Specifically explain that BusTui.connect() throws on
failure and does not perform retries, the initial "bus appears later" retry
logic is now handled by useServiceBus, and scheduleReconnect() with re-discovery
handles reconnection attempts after the bus is already running. Remove any
references to the old scheduleReconnect() approach that no longer applies, and
clearly separate the concerns: useServiceBus handles initial discovery retries,
while scheduleReconnect() handles reconnection once a bus instance exists.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

Review info

Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 5fdc6380-70ea-476e-a3cd-fa1b2dea7221

Commits

Reviewing files that changed from the base of the PR and between 084cc03 and 39b5433.

Files selected for processing (2)

• ISSUES.md
• src/bus-tui.ts

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[four-bytes-robby]

@coderabbitai — addressed in 031758c. The paragraph now clearly separates:

• BusTui.connect() → throws, no retries
• useServiceBus → handles initial discovery + retry
• scheduleReconnect() → reconnection only after instance exists

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@four-bytes-robby Thanks for the update! The separation in commit 031758c makes the distinct responsibilities clear:

• BusTui.connect() — throws on failure, no retry logic
• useServiceBus — owns initial discovery and retry
• scheduleReconnect() — reconnection only once an instance already exists

That's a clean delineation and should prevent future confusion about which layer handles what.