-
Notifications
You must be signed in to change notification settings - Fork 130
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
Bugsnag sends all reports in store regardless of releaseStage settings #405
Comments
@dwmatteson |
abigailbramble
added
backlog
We hope to fix this feature/bug in the future
scheduled
Work is starting on this feature/bug
and removed
backlog
We hope to fix this feature/bug in the future
labels
Aug 20, 2019
kattrali
added a commit
that referenced
this issue
Sep 16, 2019
A serialization bug in crash reports would erroneously allow or prevent crash reports from being delivered when the value of release stage or notify release stages were changed after start() was called, or in a subsequent build of the same app. Some values in config are serialized as nested values, while others are at the "top" level of config when written to disk. This change checks the expected position and fallback value for every config option. Fixes #405
kattrali
added a commit
that referenced
this issue
Sep 17, 2019
A serialization bug in crash reports would erroneously allow or prevent crash reports from being delivered when the value of release stage or notify release stages were changed after start() was called, or in a subsequent build of the same app. Some values in config are serialized as nested values, while others are at the "top" level of config when written to disk. This change checks the expected position and fallback value for every config option. Fixes #405
kattrali
added a commit
that referenced
this issue
Sep 17, 2019
A serialization bug in crash reports would erroneously allow or prevent crash reports from being delivered when the value of release stage or notify release stages were changed after start() was called, or in a subsequent build of the same app. Some values in config are serialized as nested values, while others are at the "top" level of config when written to disk. This change checks the expected position and fallback value for every config option. Fixes #405
Fixed in v5.22.6 |
mattdyoung
added
released
This feature/bug fix has been released
and removed
scheduled
Work is starting on this feature/bug
labels
Sep 20, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
If I have reports in the Bugsnag store (~/Library/Caches/KSCrashReports/) that were generated during Unit Testing and not sent due to releaseStage and notifyReleaseStage not matching up the next time I run the app where they do match up, it will send all the reports that are left in the store. Even if they have a releaseStage set on them that does NOT match the current notifyReleaseStage setting.
Issue
Reports are generated during unit testing with a releaseStage setting of "testing" and notifyReleaseStage setting of [ "development", "production" ]. The next time I run my app with the releaseStage set to "development" (or "production") it sends ALL the reports that are sitting in the store (all of which have a releaseStage of "testing", seen in the report files.) Note the reports are properly NOT sent when running unit tests with releaseStage set to "testing", but the files are created and written to the store. The backlog of reports are all sent the next time you run the app with a releaseStage that is valid for sending.
Environment
Library versions:
pod -v
): N/AAppDelegate
where Bugsnag is configured?Error messages:
The text was updated successfully, but these errors were encountered: