Customize subscription time

[WalrusSoup]

I'm running into an issue where a webkit webview drops connections after 60s. Pubnub, by default, listens for 280s. For periods where conversations may be idle when using the chat SDK, this causes a timeout. When interrupted, the SDK will kick up a PNBadRequestCategory error. If we attempt to reconnect the app starts falling apart unless we dispose of all the existing connections and re-connect to all existing channels.

Is there a way to customize this period? or any thoughts on a workaround?

My current workaround is to just broadcast a dead message into the users own channel with signal - but was hoping for something cleaner.

[parfeon]

Thank you for reaching out to us. Where do you receive PNBadRequestCategory when subscribe call timeout? There should be a timeout category which is handled by the subscription loop in a special way. Also, it is a status object, can you print it all console.dir(...) and share output? Or if it is a thrown exception, there should be error details as well.

[WalrusSoup]

Hey Parfeon,

Subscription call hangs out in the network tab for 60s.

Console then shows:

<HIDDEN>

Full Output:

[Log] [PUBNUB] joined channel – "f5199ec5-064e-41b3-85b8-87cdd4e48c33" (chat.ts, line 125)
[Log] [PUBNUB] joined channel – "50" (chat.ts, line 125)
[Log] [PUBNUB] joined channel – "direct.4304654671661442" (chat.ts, line 125)
[Log] [PUBNUB] joined channel – "direct.8806871637406100" (chat.ts, line 125)
[Log] [PUBNUB] joined channel – "modcon_2024" (chat.ts, line 125)
[Log] [chat] restoring last known visible channel – "f5199ec5-064e-41b3-85b8-87cdd4e48c33" (chat.ts, line 87)
[Log] [chat] changing channel to – "f5199ec5-064e-41b3-85b8-87cdd4e48c33" (chat.ts, line 300)
[Log] [chat] loading messages for – "f5199ec5-064e-41b3-85b8-87cdd4e48c33" (chat.ts, line 307)
[Log] [chat] loading messages for channel – "f5199ec5-064e-41b3-85b8-87cdd4e48c33" – {count: 100, startTimetoken: undefined} (chat.ts, line 211)
[Error] Failed to load resource: The request timed out. (0, line 0)
[Log] Status – {error: true, category: "PNBadRequestCategory", operation: "PNSubscribeOperation", …} (chat.ts, line 39)
{error: true, category: "PNBadRequestCategory", operation: "PNSubscribeOperation", statusCode: 0, errorData: TypeError: Load failed}Object
[Error] Bad category detected
    status (chat.ts:41)
    (anonymous function) (@pubnub_chat.js:1472)
    forEach
    announceStatus (@pubnub_chat.js:1471)
    processSubscribeResponse (@pubnub_chat.js:1638:207)
    (anonymous function) (@pubnub_chat.js:1625)
    (anonymous function) (@pubnub_chat.js:4340:206)

console.dir of the statusEvent

Chat.init({
  publishKey: import.meta.env.VITE_PUBNUB_PUB_KEY,
  subscribeKey: import.meta.env.VITE_PUBNUB_SUB_KEY,
  userId: userId,
  storeUserActivityTimestamps: true,
  restore: true,
}).then((chat) => {
  chat.sdk.addListener({
    status: (statusEvent) => {
      console.log('Status', statusEvent);
      if (statusEvent.category === 'PNBadRequestCategory') {
        console.error('Bad category detected');
      } else if (statusEvent.operation === 'PNUnsubscribeOperation') {
        console.error('unsubscribe hit, was this intentional?', statusEvent.affectedChannels);
      }
    },
  });
});

Currently, i'm working around it on mac by just signaling into the users channel every 50 seconds so it has something preventing it from entering this state.

[parfeon]

That is an unexpected category. Interesting, what exactly we get from WebKit when request timeout. At which environment app is built: mac or iPhone? For web view, you load local file or remote by URL?

[parfeon]

@WalrusSoup can I advise removing screenshot with web console from your response to avoid keys leakage?

[WalrusSoup]

The app is built for Mac. There is no way to adjust the timeout from what I am seeing, it's hard coded for 60s from webkit. We are loading a remote url.

The 60s applies to all requests unfortunately.

For keys, we cycled them. So all good.

[pubnub-release-bot]

@WalrusSoup this issue is addressed in v8.2.7

[parfeon]

So it wasn't lack of feature but a bug in code because of which the subscription loop didn't act properly and stopped receiving updates. Now, even if a request will be terminated earlier, it will get proper error category and the subscription loop will restart as usual and keep waiting for real-time updates. It is possible to modify your keyset by the support team to have a shorter idle interval and the server will just return a response earlier.

[WalrusSoup]

Confirmed that this latest version works and the subscription loop restarts on it's own now. Terrific! Thank you!

[parfeon]

@WalrusSoup solution for this fix struck us from behind with a different issue inside of React Native and how it may handle network issues. Can I suggest adding subscribeRequestTimeout during client configuration and specify value which is suitable for the environment? For example, if the connection dropped after 60 seconds, then set this value to subscribeRequestTimeout: 58.

Decided to contact you because I'll probably have to change the category to which this kind of error will resolve. After changes, it will be PNNetworkIssuesCategory instead of PNTimeoutCategory because of which subscribe request won't be restarted immediately, but will use reconnection manager (if the environment doesn't use PubNub with event engine enabled).