You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the connection is reset for some external reason, when trying to reconnect the FQDN should be resolved again in case it has changed.
Actual Behavior
In our case the FQDN (fcm-xmpp.googleapis.com) was always resolved to 108.177.15.188:5235 which failed every ~30 seconds with error: Error: connect ECONNREFUSED 108.177.15.188:5235
Additional Information - What happened
Some days ago, google had an issue with some components, including firebase, which affected our XMPP connection to fcm-xmpp.googleapis.com (we use this FQDN in connect options). It seems that IP that the FQDN resolves to, changed. The XMPP client tried to reconnect and every ~30 seconds got this error message: Error: connect ECONNREFUSED 108.177.15.188:5235
The issue was solved after we stopped the client and started it again. So it seems that on reconnect the XMPP client does not try to resolve again the FQDN.
The text was updated successfully, but these errors were encountered:
@xmpp/client Version
0.9.2
Expected Behavior
When the connection is reset for some external reason, when trying to reconnect the FQDN should be resolved again in case it has changed.
Actual Behavior
In our case the FQDN (fcm-xmpp.googleapis.com) was always resolved to 108.177.15.188:5235 which failed every ~30 seconds with error:
Error: connect ECONNREFUSED 108.177.15.188:5235
Additional Information - What happened
Some days ago, google had an issue with some components, including firebase, which affected our XMPP connection to fcm-xmpp.googleapis.com (we use this FQDN in connect options). It seems that IP that the FQDN resolves to, changed. The XMPP client tried to reconnect and every ~30 seconds got this error message:
Error: connect ECONNREFUSED 108.177.15.188:5235
The issue was solved after we stopped the client and started it again. So it seems that on reconnect the XMPP client does not try to resolve again the FQDN.
The text was updated successfully, but these errors were encountered: