.on('change') stops working

[behivetech]

When I implement...

client.on('change', (allFlagChanges) =>  {
       // do stuff
})

It works for about 5 minutes or so, then after a couple of failed heartbeats, it stops heartbeating and the on('change') stops working. The failure is ERR_INCOMPLETE_CHUNKED_ENCODING however the status is a 200 OK. Request URL: https://clientstream.launchdarkly.com/eval/ProbablyClientToken/ReallyReallyReallyLongToken

Is there some sort of work around for this or a way of detecting if the heartbeat is lost so I could maybe reinitialize the client or something?

[eli-darkly]

When you say "after a couple of failed heartbeats" - how are you determining that that's what's happening? What is it exactly that you're referring to as a "heartbeat"?

[behivetech]

I'm seeing calls to that url that are failing in my Chrome dev console. After the second failed call, the client.on('change' ...) aka the live updates stop working.

https://clientstream.launchdarkly.com/eval/ProbablyClientToken/ReallyReallyReallyLongToken
The error is ERR_INCOMPLETE_CHUNKED_ENCODING however the status is a 200 OK.
I replaced the tokens in the URL, but if you would like the actual URL, I can post it in a support ticket. I didn't want to post those publicly.

[eli-darkly]

This is probably best addressed in a support ticket in any case - the support team is somewhat more familiar with all the ways things can fail out in the world than the SDK developers are. To start with, they would want to know what version of the SDK you're using, and whether you're using any polyfill scripts to fill in for missing browser features (e.g. many people use a polyfill for EventSource, which is the specific feature that's having problems in this case).

What I can tell you based on the above is pretty limited:

• No, there isn't a way to detect when the stream connection is lost (btw, "heartbeat" has a specific different meaning in this context so that's why I was confused by that word). It is supposed to always reconnect, so there's no point at which it would say "I give up, it's been lost."
• EventSource has its own reconnection logic for network errors. In some cases, the connection can fail in a way that it doesn't consider to be an error and so it will not automatically reconnect. However, our SDK code adds an error handler that is supposed to detect those... so I'm not sure why it would stop trying after the first reconnect. It would be hard to determine that without tracing through the code in the debugger.
• When I've seen ERR_INCOMPLETE_CHUNKED_ENCODING mentioned before, it's usually been related to one of two things: 1. using a proxy that does not support streaming (although I would expect that to cause problems sooner than 5 minutes) or 2. the EventSource closing the connection itself due to not receiving any data within a timeout period (which usually means that the connection has already silently failed for whatever reason; our server never goes that long without sending data). Our usual timeout is in fact 5 minutes, so that is a bit suspicious. But that still doesn't answer the question of why it didn't reconnect.

[behivetech]

Thanks @eli-darkly I'll do some further investigation and send a support ticket if the issue continues. I've been working on some other things, but back to being focused on this again.

[eli-darkly]

I'm closing this now due to inactivity, but please feel free to reopen it.