Streaming connection error causes endless console logs (Error on stream connection: {"isTrusted":true})

[MattMcGlade123]

I'm using the streaming option In LD I'm getting continuous console error logs. This usually give a 503 error rather than any issue with 500. It does give an 'Access-Control-Allow-Origin' issue to. I expected the code to throw an error if there is an issue but not continuously. This is present on a new build using Hooks and an old build using the provider.

To reproduce Set up LD using the latest Hooks option (https://docs.launchdarkly.com/docs/react-sdk-reference#section-hooks). Set the Streaming URL to a url. Run the App

Expected behavior If there is an error I expect one error log to show.

Logs

SDK version "launchdarkly-react-client-sdk": "^2.14.0",

OS/platform Present on all browsers

[bwoskow-ld]

Thanks for reporting this issue, @MattMcGlade123! We'll take a look into this and will get back to you shortly.

[bwoskow-ld]

I can reproduce this issue locally. The reason for the continuous stream of errors is that the SDK attempts to re-establish the streaming connection any time that the SDK detects a failed connection. In your example, the streaming connection will always fail, and as a result there continues to be a steady stream of logged warnings. By default the re-connection attempts happen every 1000ms and a subsequent log warning happens just after. This delay is configurable.

If LaunchDarkly was to clarify the reason for the multiple notifications, without actually diminishing the number or frequency of them, would this be a sufficient solution? I was thinking that we could update the "Error on stream connection" warning to say that a retry will occur soon.

Alternatively we could update the SDK's logic so that a warning is logged only for the first attempt (resetting each time a connection is successfully established). However, this seems less desirable to me as (I think) it is desirable to log every time this happens to at least provide context to the constant stream of GET 503 errors which would be happening regardless due to the retry policy and the consistently failing reconnections.

[bwoskow-ld]

If you're additionally concerned about the stream of GET errors and not just the logged warnings -- those happen because of the SDK's retry policy. This retry policy is desired because if an SDK is configured to use streaming, and the SDK's streaming connection has failed, then it wants to reattempt to establish a connection as soon as possible so as to have a minimal service disruption.

As mentioned above, the retry policy is to reattempt the connection every 1000ms by default, although this value is configurable. With my proposed change, the error message which accompanies a failed reconnection would at least state that a retry is going to occur.

[MattMcGlade123]

@bwoskow-ld, I can see why you'd not want to log for the first attempt so a better error message would be better. Is the streaming url different for the initial call url as this only happens when we are using the streaming. We can disable that but as we are using react there won't be a page reload so we'd need to keep it going.

[bwoskow-ld]

All connection attempts (first and subsequent) use the same URL. There isn't a different URL for the first attempt. When one of my proposals above said that we'd have different behavior for the first error, that was only in regards to the logging behavior; the actual connection logic would be unmodified.

Separate from the topic of how we should log the error -- have you previously successfully streamed with this configured streamUrl? From the second error "No 'Access-Control-Allow-Origin' header is present on the required resource" I believe that your ecslive-launchdarkly-core-elb proxy is not passing CORS headers along.

[bwoskow-ld]

A quick update on this issue -- I've implemented a change so that the "Error on stream connection..." message 1) mentions that the SDK is going to retry establishing the connection and 2) is only logged on the first failed attempt. More specifically, this is the first failed attempt in each series of failures; if the SDK fails to connect one or more times, then successfully connects, then disconnects and again fails to connect one or more times, the message will be logged twice-- at the start of each failure series.

This change affects the behavior in each of our client-side JavaScript-related SDKs: JavaScript, React, Node.js (client-side), and Electron. It'll be included in an upcoming release of each.

As for your particular problem -- see my note in my previous comment regarding CORS headers.

[MattMcGlade123]

@bwoskow-ld I'm knew to my company and the person how I replaced has left so I'm not certain if it ever worked. It may be because they've not pushed the header as you suggested. I'll check with other members of the team.

Ok thanks for the update tot he message. If we push the headers though hopefully we won't receive any more errors

[eli-darkly]

By the way, we've just released version 2.15.0, which includes the logging change described above by @bwoskow-ld.

[benfluleck]

Hi I am still getting this warning as well my sdk version is "launchdarkly-react-client-sdk": "^2.20.1" and I am using react 16.13. Please any advice would be appreciated cc @eli-darkly @bwoskow-ld

[bwoskow-ld]

@benfluleck can you provide your console log with the error(s)? Are you seeing this error only on the first failed connection attempt or also on subsequent attempts?

[benfluleck]

[bwoskow-ld]

Hi @benfluleck ,

My best guess about what's happening here is that your app's streaming connection with LaunchDarkly is being periodically disconnected. The hint here is ERR_INCOMPLETE_CHUNKED_ENCODING -- which signals that the connection was established successfully and subsequently terminated. This also makes sense as to why you're seeing the error multiple times; the SDK will warn about a stream connection error for the first error in each sequence, but after a successful connection, this state is reset and thus if a subsequent error happens after a successful connection, another warning will be logged.

I've seen cases where anti-virus software or other networking conditions (outside of LaunchDarkly or the SDK's control) can cause errors like this.

If you need additional assistance from LaunchDarkly, I recommend reaching out to our support team. However, I do suspect that this is an issue on your side.

Cheers, Ben

P.S. I recommend filing a new GitHub issue next time you have a problem, as opposed to commenting on a closed ticket. It is too easy for the repository maintainers like myself to miss activity on closed tickets.

[vishwaratna]

Make sure that you are not behind any VPN.