ConnectionManager: always allow event queueing while connecting #1039
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Even if was previously suspended or after a failed connection freshness check
The current behaviour is there so that after you go into suspended, and
starts new connection attempts every 30s, it'll still reject publishes
immediately unless/until it becomes connected again. But this results in
some slightly unintuitive behaviour post-device-wake -- an eg presence
enter might fail milliseconds before the sdk reconnects, because it was
never actually having connectivity issues it was just asleep, and it
would have been fine to queue it. Queueing messages for a few seconds
during a connecting cycle (and then failing them if the attempt fails
and the sdk falls back into the suspended state) wouldn't be so bad.
Made the analagous change to the suspended state as well because if you
just remove the connection.queueevents=false line in the freshness
check, but then it fails that and then can't reconnect and goes into
suspended, it would behave differently from if it goes into suspended
via the suspendTimer.
(TBH I've never liked how we mutate the states struct in this way in
various places. IMO would be a lot more elegant to have a completely
frozen states struct, junk the suspendTimer, and decide whether to go
into suspended just by special-casing disconnected in notifystate,
checking how long it's been since we were last connected, and
substituting suspended if it's been over 2 minutes, or something like
that. But that's a change for another time.)
I don't think this change is against the spec, which leaves this ambiguous.