If there are errors that are caused by network issues (like network timeout, socket timeout etc) then it is best to ignore those errors. Putting a fix to create more use-friendly error is not a very good use of time because - the number of different type of errors that one may get is very large. Secondly these errors can keep coming from different sources and hence one cannot completely handle them in the code.
DISCARD then IGNORE
Make a note of this on the Bugsnag issue.
Note this applies only to web app and server which are online systems. In such cases one should mark it as fixed. This means that if such an issue is reported again then it has not been fixed.
DO NOTHING (as by discarding one may lose the issue after 7 days). Mark Zenhub issue as high priority.
If an error is reported only because the code deals with it as an unhandled exception but it is a normal scenario then in such cases the code should be fixed. e.g. Login Failed because of bad credentials, or access denied, or random requests to the server on endpoints that don't exist (note in this case the client error may be relevant as the client is sending the request to the wrong endpoint but there is nothing to be done on the server).
If an error is reported due to configuration issue then do not ignore the issue. Treat it as normal error.
If this happens then perhaps it is due to some miss during the release process. Sourcemap should be uploaded.
Mark as FIXED
- We should look at last 30 days, errors happening in production environment and not on developer machines (applies to emulators).
- You can look at additional information available in Bugsnag in its tabs like Release stages, Users, Models etc.
- Usually the higher frequency of error should be paid more attention to, in terms of prioritisation (note this applies across projects i.e. a higher frequency of server error is likely more important to fix than lower frequency client error and vice-versa).
- If an error doesn't have a source map associated with it then raise a bug to get the source map uploaded for that version.
- Use and maintain the bookmark created for analysis called - Production Open Issues.
- Check comment on the issue to check whether the issue is linked to Zenhub issue already. It is not linked via their issue tracking to Github as not sure what that will get us.
- When ignoring an issue, first discard it and then ignore it.
- Look for issue template in Zenhub/Github and add if necessary.
- Look for Zenhub issue from the comment on BugSnag issue
Updated 3 months ago