fix: cancel in-flight connect on disconnect to prevent second-attempt bug

[staging-devin-ai-integration]

Summary

Fixes a race condition where disconnect() during an in-flight performConnect() could not cancel it, causing the "start a pipeline → destroy → start a new one" flow to break reliably.

Root cause: performConnect() creates MoQ resources (Camera, Connection, etc.) in local variables that aren't stored in the Zustand store until the final success set(). When disconnect() runs mid-connect, cleanupConnectAttempt() only sees null refs in the store — the in-flight objects are never cleaned up. The stale performConnect₁ then overwrites the store when it eventually completes or times out, clobbering performConnect₂'s state.

Fix: Add an AbortController to the store. disconnect() and connect() abort any in-flight attempt. AbortSignal is threaded through every async wait (waitForSignalValue, waitForBroadcastAnnouncement, setupMediaSources, setupPublishPath). An aborted performConnect cleans up its local resources and silently returns without writing to the store.

UX improvements:

• Added connectingStep state ('devices' → 'relay' → 'pipeline') shown during the connecting phase so users see what's happening instead of a generic "Connecting…"
• Auto-connect errors after session creation are now surfaced to the user instead of being silently logged

Refactors:

• Extracted createConnectionAndHealth() and connectWatchPath() helpers from performConnect to stay under the max-statements lint threshold

Review & Testing Checklist for Human

• Critical: Test the second-attempt flow — Create a pipeline session, let it connect, destroy it, then immediately create a new one. The new session should connect successfully without getting stuck.
• Test rapid disconnect/reconnect — While "Connecting…" is showing, click disconnect, then immediately create a new session and connect. Should not hang or show stale state.
• Verify connecting step labels — During connect, the status line should show phases like "Connecting — Requesting device access", "Connecting — Connecting to relay", etc.
• Verify error surfacing — If the MoQ gateway is unreachable, the error should be shown to the user after session creation (not silently swallowed).

Notes

• All 303 existing UI tests pass, plus 7 new tests for abort signal cancellation and disconnect-during-connect behavior.
• Lint passes clean (0 errors, only 1 pre-existing warning in an unrelated file).
• The AbortSignal integration uses DOMException('Aborted', 'AbortError') which is the standard Web API pattern.

Link to Devin session: https://staging.itsdev.in/sessions/8352254860d447efb51e249658d0eaf0
Requested by: @streamer45

---

[staging-devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[staging-devin-ai-integration]

Devin Review found 2 potential issues.

View 3 additional findings in Devin Review.

Debug

Playground

[staging-devin-ai-integration]

E2E Test Results — Connect Lifecycle Fixes

Ran Puppeteer headless Chrome (--use-fake-device-for-media-stream) against local dev environment (skit backend :4545, Vite UI :3045). Template: "Webcam Circle PiP (MoQ Stream)".

Test Results (5/5 passed)

• TC1: Connecting step feedback shows granular phases — passed. MutationObserver captured "Connecting — Requesting device access • Watch: loading… • Mic: requesting permission… • Camera: requesting permission…". The em-dash + step text are unique to the new code.
• TC2a: Disconnect returns to disconnected state — passed. "Connect & Stream" button reappeared and was enabled after clicking Disconnect.
• TC2b: Second connect attempt works (not stuck) — passed. Fresh "Connecting — Requesting device access" captured on reconnect, reached Connected state. This was the critical bug fix — previously the stale first performConnect would clobber the second attempt's state.
• TC3a: Destroy session returns to initial state — passed. Confirm dialog worked, UI returned to initial state with "Create Session" enabled.
• TC3b: New session after destroy auto-connects successfully — passed. Auto-connect fired with fresh connecting step feedback, reached Relay: connected • Watch: live • Mic: ready • Camera: ready.

Status progression captured by MutationObserver (TC1)

1. STATUS:Disconnected
2. Connecting — Requesting device access • Watch: loading… • Mic: requesting permission… • Camera: requesting permission…
3. Relay: connected • Watch: loading… • Mic: requesting permission… • Camera: requesting permission…
4. STATUS:Connected
5. Relay: connected • Watch: live • Mic: ready • Camera: ready

Caveats

• Fake media devices provide instant access, so only the "devices" connecting step was captured. "Connecting to relay" and "Waiting for pipeline" steps transition too fast with a local backend.
• Not tested: real camera permission UX, WebTransport over real network, error recovery when backend is down.

Screenshots

Initial State	Connected

After Disconnect	Second Connect Result

Destroy Confirm	After Destroy

New Session After Destroy

Devin session