fix: remove fire-and-forget reconnect() from initConnection() catch block (OPTI-2437)

[devin-ai-integration]

Summary

Removes fire-and-forget this.reconnect() calls from the tokenGenerator() catch blocks in both View.js and Publish.js initConnection() methods.

When tokenGenerator() throws a FetchError with a non-401 status and autoReconnect is enabled, the old code called this.reconnect() without awaiting it, then immediately re-threw the error. This created a double-retry path:

• Via reconnect() → connect() → initConnection(): The re-thrown error propagates back to BaseWebRTC.reconnect()'s catch block, which schedules a retry via setTimeout with exponential backoff. Meanwhile, the fire-and-forget this.reconnect() is usually blocked by the isReconnecting guard — but not always.
• Via direct connect() call: isReconnecting is false, so the fire-and-forget this.reconnect() passes the guard and starts a full independent reconnect loop. The re-thrown error also reaches the user, who may retry, resulting in two parallel loops.

In all cases, the fire-and-forget call also produced an unhandled promise rejection.

The fix relies on BaseWebRTC.reconnect() to handle all retry logic (it already does, with exponential backoff). The stopReconnection = true behavior for 401 errors and autoReconnect=false is preserved.

Jira: OPTI-2437

Review & Testing Checklist for Human

• Verify behavioral change for direct connect() callers is acceptable. Previously, calling connect() when tokenGenerator threw a retryable FetchError (e.g. 500) would silently start a reconnect loop. Now, the error propagates to the caller without triggering automatic reconnection. This is intentional but is a breaking behavioral change for consumers who relied on this implicit retry-on-first-connect.
• Confirm the reconnect() → connect() → initConnection() path still retries correctly. The thrown error should propagate to BaseWebRTC.reconnect()'s catch block (line 145), which resets isReconnecting and schedules a retry via setTimeout. Trace this manually or with a debugger.
• Consider whether new test coverage is needed. No existing tests cover tokenGenerator throwing a FetchError during reconnection. The existing reconnect tests mock reconnect() entirely, so this interaction path is untested before and after this change.

Notes

• The identical pattern existed in both View.js and Publish.js — both are fixed.
• initConnection() resets this.stopReconnection = false at its start, so for non-401 retryable errors the flag remains false, correctly allowing the outer reconnect() loop to continue.

Link to Devin session: https://dolby.devinenterprise.com/sessions/8efd8a57246d4539b83a9534d7b0f60e
Requested by: @craig-johnston

---

[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

[changeset-bot]

⚠️ No Changeset found

Latest commit: 930dab0

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 3 additional findings.