Errors are just Issues with additional content

We are working on our Error Tracking feature of GitLab, and trying to decide how this should look and work in GitLab.

One option is that we have a special workflow just for errors. They get their own sidebar, you can search on them, link them to issues, etc. Another option however, is that errors are simply issues.

Errors as Issues

Frequently when an error is opened, users would then open an issue to drive it to conclusion. There are a number of services that do this already like Zapier for Sentry, and a number of feature requests to add this directly to Sentry: https://github.com/getsentry/sentry/issues/600. Since we own both sides though, can we do better?

In considering the GitLab workflow, I'm not sure it makes sense to have another workflow dedicated just to errors:

• Users will frequently be opening up issues to fix these errors, and having to link them, so why not just have them be the same thing and save everyone time?
• Errors would also need the ability to be commented on, linked, assigned, labeled etc. Why build all this workflow when it already exists for issues?
• A merge request can already close an issue, which should then also close the error once the commit is deployed.

Challenges with this approach:

• We will need a way to cleanly extend the Issues workflow without adding a lot of weight or unnecessary UI. I was thinking this could take the form of a special embed code in the Issue, whereupon it would insert a "card" with the error details.
• Searching for errors may be more difficult, unless you can also search for specific error fields or tags. We also don't want to overcomplicate the issue search interface.
• Summary reporting and stats could still live elsewhere, perhaps on Ops -> Errors. We'd just need a way to specific find these special issues.