Open CamilleDrapier opened 1 year ago
Would be nice to have a way to reproduce. Which server / version? What is the code that reproduce the problem ?
Anyhow - could you check if the following fixes the problem: https://github.com/xmppjs/xmpp.js/pull/967
after explicitly calling the client close method
Did you mean the stop
method?
Thank you for your reply!
I do not think I can provide a way to reproduce, as this happens only sometimes with our quite complex setup that I cannot share publicly, sorry. I noticed this problem with the 0.13.1
client at least. I'm not sure about the server though!
Anyhow - could you check if the following fixes the problem: https://github.com/xmppjs/xmpp.js/pull/967
Thanks! I think the changes looks nice, but I do not think it would solve the problem I described:
closing
event to be handled before a disconnecting
event.closing
get processed before a disconnecting
, if would still end up in a diconnected
state wouldn't it?Of course, I'm not very proficient with the code base here, so I might have missed some side effect of your proposed changes that would solve the problem :bow:
Did you mean the stop method?
Yes, sorry for the confusion!
Describe the bug
When calling
stop()
, we expect the client to end up in the 'offline' status, but sometimes (somewhat extreme network environment?) the 'offline' event is triggered before the 'disconnected' one, which will then keep the 'disconnected' until other actions are triggered. If the reconnect package/plugin is used, it will identify this state as necessitating re-connection and will try to perform a re-connection (which will usually not succeed)Logs
Environment
This is obtained by running our application through some integration testing (cypress 10.3.1 + Chrome 104.0.5112.79, observed on both CI (ubuntu), Mac, and Linux (Arch) computers)
Possible Solutions and workaround
One possible solution would be to not mark the 'disconnected' state if we are currently in
offline
state, maybe on the connection package we could do something such as:Otherwise for now, as a workaround, we will disable the reconnect mechanism after explicitly calling the client close method to avoid the client trying to reconnect (but it will still be left in an unexpected state/status):