startConnection() already catches hub.start() failures, sets disconnected state, calls attemptReconnect(), and does not rethrow. The timeout catch is therefore unreachable in production.
If a later change adds throw error inside startConnection's catch, this outer catch would double-schedule reconnect (once from startConnection, once from the timeout).
Fix: either rethrow from startConnection and drop the inner attemptReconnect(), or delete the timeout catch and rely on the inner one.
In `projects/spikersoft/src/app/_components/calendar/services/signalr.service.ts`, `attemptReconnect()` schedules:
```ts
setTimeout(async () => {
try {
await this.startConnection();
} catch (error) {
console.error("Reconnection attempt failed:", error);
this.attemptReconnect();
}
}, this.reconnectDelay * this.reconnectAttempts);
```
`startConnection()` already catches `hub.start()` failures, sets disconnected state, calls `attemptReconnect()`, and **does not rethrow**. The timeout `catch` is therefore unreachable in production.
If a later change adds `throw error` inside `startConnection`'s catch, this outer catch would *double-schedule* reconnect (once from `startConnection`, once from the timeout).
Fix: either rethrow from `startConnection` and drop the inner `attemptReconnect()`, or delete the timeout catch and rely on the inner one.
Resolved in spikersoft-angular PR #818 (merged to master). Removed the dead SignalR timeout catch so reconnect is scheduled only from startConnection. Closing.
Resolved in spikersoft-angular [PR #818](https://git.spikersoft.com/spikerj/spikersoft-angular/pulls/818) (merged to `master`). Removed the dead SignalR timeout catch so reconnect is scheduled only from `startConnection`. Closing.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
In
projects/spikersoft/src/app/_components/calendar/services/signalr.service.ts,attemptReconnect()schedules:startConnection()already catcheshub.start()failures, sets disconnected state, callsattemptReconnect(), and does not rethrow. The timeoutcatchis therefore unreachable in production.If a later change adds
throw errorinsidestartConnection's catch, this outer catch would double-schedule reconnect (once fromstartConnection, once from the timeout).Fix: either rethrow from
startConnectionand drop the innerattemptReconnect(), or delete the timeout catch and rely on the inner one.Resolved in spikersoft-angular PR #818 (merged to
master). Removed the dead SignalR timeout catch so reconnect is scheduled only fromstartConnection. Closing.