-
Notifications
You must be signed in to change notification settings - Fork 129
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
Allow Bugsnag to return current metadata, across all sections #865
Comments
Hey @bolsinga, the metadata is retrievable at:
For example, the following: let config = BugsnagConfiguration.loadConfig()
config.addMetadata("Acme Co.", key:"name", section:"account")
config.addMetadata(true, key:"paying_customer", section:"account")
config.addOnSendError { (event) -> Bool in
dump(event.getMetadata(section:"account"))
return true
}
// ...
// Wrapped in an @IBAction of a button
dump(Bugsnag.getMetadata(section:"account")) Results in the following for both the
Hopefully this helps cover what you're looking to achieve! You mentioned that you were unable to read the metadata in your original post, so If I've misinterpreted your question, please do get back in touch 😄 |
Hi @xander-jones Yes, I saw that about meta data for a given section. I'd like to get all the meta data, since I do not know what sections my clients may add. Those API would work if I could also get all the sections back via something like |
Description
In #747 access to the breadcrumbs was provided. Thanks! It would be nice to also have read access to the current metadata.
Describe the solution you'd like
Clients can write to the metadata, but cannot read it. If they could read it, it would be useful. Basically it will allow clients to use Bugsnag as a data store for "interesting developer information" that could be surfaced in an in-app bug reporter. This way our in=app bug reports will have the same data as crash reports, making for a terrific developer experience.
Describe alternatives you've considered
Clients could track everything being sent to Bugsnag, but this would create duplication of data. It may also be error prone.
Additional context
Our app has an in-app bug report mechanism, and the data there isn't the same as in crash reports. We have a goal of making the developer experience better when something "bad" happens, and a common data store would help out in that regard.
The text was updated successfully, but these errors were encountered: