Feature: Close non-fatals based on parameters.

[jostster]

Feature proposal

• Firebase Component: Crashlytics

Ability to close a set of non-fatals that match parameters. If you log non-fatals such as error codes that users encounter, then fix a set of those (for example those with 500 codes), it would be nice to be able to close those instances that have the 500 non fatal codes.
Could be used in conjunction with #6915

[samedson]

Hey @jostster I'm curious how the experience around this works today. Is the issue that the non-fatals you have are grouping, for example, 400-level and 500-level response code errors together? Would you consider throwing different types of errors for different response codes, or would that break your workflow in some other way?

[jostster]

So the way it was setup by the previous developer is for example network errors have an error code IE (1234). The details will show the reason returned by the api such as, invalid login, expired session, access denied, etc. It would be nice to be able to filter and close all of the 1234 networkError's that have expired sessions params.

I believe switching it to be by error code would make all our different modules errors grouped together. For example a 500 login error could be different from a store checkout 500 error which we would want to monitor differently.