Skip to content
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

Closed
dwmatteson opened this issue Aug 19, 2019 · 2 comments · Fixed by #412
Closed

Bugsnag sends all reports in store regardless of releaseStage settings #405

dwmatteson opened this issue Aug 19, 2019 · 2 comments · Fixed by #412
Labels
bug Confirmed bug released This feature/bug fix has been released

Comments

@dwmatteson
Copy link

dwmatteson commented Aug 19, 2019

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:

  • Bugsnag version bugsnag-cocoa-5.22.4
  • CocoaPods version (if any) (pod -v): N/A
  • Carthage version (if any): N/A
  • iOS/tvOS/macOS version(s) macOS 10.14.6
  • debug mode or production?: Debug
  • How are you initializing Bugsnag? Can you share a snippet of your
    AppDelegate where Bugsnag is configured?
import Bugsnag

// Normal initialization
        let bugSnagConfig = BugsnagConfiguration()
        bugSnagConfig.apiKey = Constants.BugSnagKey
        bugSnagConfig.notifyReleaseStages = [ "development", "production" ]
        // tried to do this as a way to circumvent the described behavior, but it doesn't work.
        bugSnagConfig.add(beforeSend: { (rawData, report) -> Bool in
            // note this doesn't work because releaseStage is always nil on the report object....
            if(report.releaseStage == "testing") {
                return false
            }
            
            return true
        })

        Bugsnag.start(with: bugSnagConfig)

// In unit tests' setUp() method
Bugsnag.configuration()?.releaseStage = "testing"
Error messages:
None
@mattdyoung mattdyoung added the bug Confirmed bug label Aug 20, 2019
@mattdyoung
Copy link

@dwmatteson
That does sound like it may be a bug. We'll investigate and confirm whether this needs a fix or whether there's a different way to configure this that works.

@abigailbramble 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
@mattdyoung
Copy link

Fixed in v5.22.6

@mattdyoung 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
Labels
bug Confirmed bug released This feature/bug fix has been released
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants