Amplify-js: How to catch PubSub errors if MQTT connection lost or broken?

[mevert]

* Which Category is your question related to? *
PubSub connection problems

* What AWS Services are you utilizing? *
PubSub in aws-amplify 1.1.19

* Provide additional details e.g. code snippets *
What is the best way to keep PubSub connection alive by using aws-amplify? Or is there even any way?

I am using similar code as you mention in the documentation:
PubSub.subscribe(['myTopic1','myTopic1']).subscribe({ next: data => console.log('Message received', data), error: error => console.error(error), // this never logs anything) close: () => console.log('Done'), // this never logs anything) })

However, I have the problem that clients Internet connection can be lost for a short period of time and then these can no longer receive messages. For example, if portable Wifi router switch connection from 4G to 3G, I get the following message in console:
ConsoleLogger.js:88 [WARN] 14:36.405 MqttOverWSProvider - ... { "errorCode": 4, "errorMessage": "AMQJS0004E Ping timed out.", "uri": "wss://..." }
I would like to catch these connection problems somehow in order to subscribe to topics again so that I can keep connection alive.

[manueliglesias]

Hi @mevert

At the moment, there is no way to catch those events.

https://github.com/aws-amplify/amplify-js/blob/e7157dc797c76b66b79f069705428a0bc8e2d054/packages/pubsub/src/Providers/MqttOverWSProvider.ts#L99-L101

Which, as of today, only logs a warning:

https://github.com/aws-amplify/amplify-js/blob/e7157dc797c76b66b79f069705428a0bc8e2d054/packages/pubsub/src/Providers/MqttOverWSProvider.ts#L85-L89

If you are on a browser environment, one thing you can try is the Navigator online api to listen for connection changes and unsubscribe/re-subscribe accordingly.

I am also labeling this as a feature-request

[nayan27]

This seems closely linked to my own issue: #2007 . I believe we really need a way to handle connection status properly. I also believe that should be fairly easy to implement/test/release. After looking at the lines provided above, the only missing thing is a connection event callback which we could pass to the MqttOverWSProvider. This callback could then be called in the MqttOverWSProvider.onDisconnect method and other connection related methods.
Thank you!

[matwerber1]

+1 request for connection event handlers and methods to retrieve current status. Same for subscriptions if not already present.

For example, in code below, no errors are thrown even if I provide non-existent region or endpoint:

Amplify.addPluggable(new AWSIoTProvider({
      aws_pubsub_region: AWSIotConfiguration.region,
      aws_pubsub_endpoint: AWSIotConfiguration.endpoint,
    }));  

However, I later receive an uncaught (in promise) error when attempting the PubSub.subscribe() action. If we could know that the connection failed in advance we could avoid the unecessary subscription attempt.

[mevert]

In addition to AMQJS0004E Ping timed out error, AMQJS0007E Socket error:undefined (errorCode: 7) does not trigger the error. Despite the fact that it occurs when subscription fails. Documentation of PubSub says that error is "Triggered when subscription attempt fails". However, looks like errors are not triggered...

@manueliglesias any idea when the fix for this issue is coming?

[schaq8]

+1 request for connection event handlers and methods to retrieve current status. Same for subscriptions if not already present.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[amazing-Mantse]

+1 request to fix AMQJS0004E Ping timed out. Also experiencing the same issue.

[mevert]

Dear, aws-amplify developers, could you please comment on this issue and let us know when the fix for catching PubSub errors is coming?

[elorzafe]

@mevert are you still having the issue with AMQJS0007E? That problem was fixed on pr #3376

[mevert]

@elorzafe thanks for the info. I will let you know if I face the problem again. What is the status with the connection handlers? And are we now able to know when IoT connection breaks in all of the possible cases?

Currently, I have used PING/PONG check for websockets in order make sure that WS connection is still alive and working because I wasn't able to catch all broken connections with aws-amplify. So I have been calling backend Lambda that will send IoT message to the client and if client won't receive the message in a certain amount of time it will try to initialize Websocket connections.

[elorzafe]

@mevert can your our latest unstable release. (1.1.37-unstable.10 for aws-amplify)

[mevert]

@mevert can your our latest unstable release. (1.1.37-unstable.10 for aws-amplify)

After updating aws-amplify version to 1.1.40 it broke our PubSub subscriptions unsubscribe funktion as described in https://github.com/aws-amplify/amplify-js/issues/3039#issuecomment-532222215 We can no longer subscribe again to topics that were unsubscribed.

From the old package-lock.json I can see that in @aws-amplify/pubsub version 1.0.30 unsubscribe used to work. However, with the current 1.1.2 we have this problem. @elorzafe any ideas why? Edit: Looks like @aws-amplify/pubsub 1.1.0 is the last one that works.

[justinjoyn]

Any update on this? I always get this error when trying to subscribe to a topic after internet is restored.

     "errorCode":7,
     "errorMessage":"AMQJS0007E Socket error:undefined."

[escar]

Any update on this? I always get this error when trying to subscribe to a topic after internet is restored.

     "errorCode":7,
     "errorMessage":"AMQJS0007E Socket error:undefined."

Same here, I'm on latest version 2.2.5

[Thembelani]

Hi. Any update on this ...?

[zhenyakovalyov]

hi - is there any updates on this please?

[CiscoKidxx]

Hello, looking for an update here please!

[ericclemmons]

https://github.com/aws-amplify/amplify-js/pull/6448 should address this issue.

error will fire when the connection closes unexpectedly, allowing you to fire PubSub.subscribe again.

Please open a new issue (which includes a new bug report template) if you experience this problem again 🙏

[blacksheep--]

@ericclemmons this is wrong, as the mentioned PR #6448 covers changes to AWSAppSyncRealTimeProvider and the necessary (and also mentioned by OP) MqttOverWSProvider has not been touched since 20th March 2020. So this bug is still alive.