-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CRASH: LDClient.go(online:reasonOnlineUnavailable:completion:) #235
Comments
Hi @NishanthMurugan thank you for reporting this. This seems like it might be an issue related to your implementation, please reach out to support@launchdarkly.com so you can provide us with additional context for this crash in a confidential manner. |
Sure @torchhound. If it is implementation issue, this crash should happen all the time right. |
We just observed a series of similar crash traces starting shortly after we changed the name and description of a feature flag on the LaunchDarkly console (the flag's |
I work with provTheodoreNewell above, and we continue to investigate this issue and confer with LD support. (we also don't believe it's related to the feature-flag rename Theodore cited above.) The crashes we observed have also been time-constrained in that they appeared between 230p-4p PST and we haven't seen any since. We have been able to consistently reproduce crashes in the SDK v5.3.1 when we throttle network speeds to 256k/3G, something we haven't been able to reproduce with earlier versions of the SDK. |
Any updates on this crash? Although I am unsure if any flags were modified like mentioned above. I am also not seeing a bunch of crashes during a short period of time. Our crashes are more spread out but they started on December 23rd on our production build even though we added Launch Darkly back in September. We are using Launch Darkly version 5.1 through cocoapods. Please let me know if any additional info is needed to determine if its a potential issue with how I am implementing the cocoapod vs an issue with Launch Darkly itself. |
@bwoskow-ld You closed my ticket and said you wanted to consolidate the conversation here. But LD hasn't had any input here for 13 days and no one is assigned to it. A 3rd party SDK crashing our app is a serious issue for us. Especially if it's from a service that's paid for. |
We are currently investigating the issue. We'll update everyone on this GitHub issue when we have more information. Our team doesn't actively use GitHub's assignee feature on issues; we have a private issue tracker which we use for managing all of our tasks across all of our repositories. |
@bwoskow-ld Thank you for the update, please let me know if there's any additional info I can provide to help you and your team investigate the issue. |
We are also experiencing this crash. Let me know if any info that I can provide that could help with the fix. |
I'm also experiencing this issue. Please keep everyone posted with progress or information regarding this crash. I am using the streaming functionality and not polling. Any chance it is related to streaming feature flag updates? |
Hi all, We are currently investigating this issue. In some cases it seems like this could be caused by calling |
## [5.3.2] - 2021-02-11 ### Fixed - Updated to prevent a crash in `dispatch_group_leave.cold.1` that would rarely occur as the SDK transitioned to an online state for a given configuration or user. This issue may have been exacerbated for a short period due to a temporary change in the behavior of the LaunchDarkly service streaming endpoint. Thanks to all the users who reported ([#235](#235)). - Updated `LDSwiftEventSource` dependency to correct an issue where a streaming connection could sometimes reconnect after being set offline.
We've just released 5.3.2 to address this issue. After investigation, we found multiple probable contributing factors. There was a temporary change to data being served by the streaming endpoint of the LaunchDarkly service that corresponded with the increase of issue reports. The original behavior of the streaming endpoint was restored after our internal integration testing showed a decrease in reliability for our mobile SDKs. Regardless, the SDK should not have experienced crashes from that change. In the release we've added protections to prevent this Feel free to reach out here or to our support team if experience any more issues. Thanks for the patience, |
We got this issue reported in our crash reporting today. Did you have a similar issue as last time? |
This pull request was auto generated by the Launchdarkly Github Standards automation platform. * Add default CODEOWNERS file
Hi Team,
we got many crash on this in a single day. please help to resolve.
The text was updated successfully, but these errors were encountered: