-
Notifications
You must be signed in to change notification settings - Fork 14
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
Additional http headers for websocket connection #47
Conversation
… websocket connection
Allow to set HTTP Headers
I had a quick check. looks good. I'll give it a deep one in about 1.5h. Maybe I'll get to merge it today :) |
Great! Thnx! Looking forward it!) |
@konsultaner Hi! I've added tests. Pls have a look. It's a little bit ugly, but don't want to create more complex flow. But I adopt it if you suggest something else. |
Gentle reminder about PR :) |
It took time but seems all is cleared now. Tests are passing. @konsultaner Can you have a look? |
I was on a shorts holiday. Will have a look at it tomorrow morning 🤟 |
Codecov ReportBase: 91.47% // Head: 91.47% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #47 +/- ##
=======================================
Coverage 91.47% 91.47%
=======================================
Files 41 41
Lines 2639 2640 +1
=======================================
+ Hits 2414 2415 +1
Misses 225 225
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
try { | ||
var session = await Session.start(realm, transport, | ||
authId: authId, | ||
authRole: authRole, | ||
authMethods: authenticationMethods, | ||
reconnect: options.reconnectTime); | ||
_controller.add(session); | ||
|
||
unawaited(transport.onConnectionLost!.future.then((_) async { | ||
// Trying to reconnect only if we were connected and there is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get the point, but what If the router crashes and auto heals. The there will be only one reconnect. I guess the point was to not reconnect if the credentials were wrong?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @konsultaner! Great that you get to this!
Yeah, original idea was not to reconnect when it is not useful, like with bad credentials.
The code in client.dart
is a little bit complicated... Maybe we can refactor this in future :)
So if you know how to resolve this problem in more elegant way — please suggest!
I really like that you considered a different reconnect strategy. I'm not sure this will work in an auto-healing environment. We may have to consider a more complex reconnect strategy depending on the reason why it didn't work or maybe have it configurable? What do you think @KSDaemon |
Yeah! Right now lib operates only on transport state to take decision: reconnect or not. But there are cases when session state must be taken into account. Can you describe a bit more about |
So in the first run, there are the next points of connection failure and reconnection:
|
With auto healing I basically mean either:
or
I totally agree with:
seems like I have to add some more logic to that. I think will will add this during the week. I need the connectanum-dart for one of my projects too. So finally will have a real live application myself. I will have to add some stuff like auto-resubscribe and other things. Maybe you take this part off this pull request and add an issue I will work on? Or if you are willing to contribute, feel free to add this logic! |
Okay! Let me then close this PR, I'll make a new one without these changes, also I'll file a new issue about May be you can add me as a contributor? Just for a convenient way of creating issues, reviews etc? |
Closing in favor of #49 |
AUTHENTICATION_FAILED