Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not reconnect if first connection failed #3

Open
gcoda opened this issue Apr 30, 2024 · 3 comments
Open

Does not reconnect if first connection failed #3

gcoda opened this issue Apr 30, 2024 · 3 comments

Comments

@gcoda
Copy link

gcoda commented Apr 30, 2024

I suspect this should be handled by @microsoft/signalr package.
But it does not even try to reconnect if connection.start() failed.

is it ok to reuse "private" function from ConnectionHub object inside createService -> init() -> catch { ... here ... }

something like this gcoda@980329e

@IlCallo
Copy link
Member

IlCallo commented May 2, 2024

I wouldn't call init function recursively and I'd use one of the existing packages for exponential backoff retry management

This means the "happy path" of the init function should be extracted to its own private function, let's call it connectAndProcessActions, which throws in case of a failed connection

Then init would use connectAndProcessActions applying the exponential backoff pattern and only executing the failFn if the max number of retries is reached

Also, I'd properly manage TS to avoid the connection as any casting and the //@ts-ignore
If you definitely need that, at least use //@ts-expect-error instead

If you wanna apply these fixes and send a PR, I can review it

Otherwise, if you use this into a commercial project, please check out our sponsorship page to get issue prioritization: github.com/sponsors/dreamonkey/sponsorships?tier_id=135990

@IlCallo
Copy link
Member

IlCallo commented May 2, 2024

This is a quick example on how to implement an exponential backoff retry pattern: vuejs/apollo@b17817e

@gcoda
Copy link
Author

gcoda commented May 7, 2024

Then init would use connectAndProcessActions applying the exponential backoff pattern and only executing the failFn if the max number of retries is reached

i wanted to reuse reconnect function provided and supported by ConnectionHubBuilder, it is a bit weird to write two different reconnect retry handlers, one for initial connect and another for broken connection, maybe i should just modify .start() function in HubConnection\IConnection from ConnectionHubBuilder object instead

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants