We currently send errors from a service application and the part of another application that calls into that service to a single Sentry project. (The client application sends other, unrelated errors to other Sentry projects.)
This is useful for scoping the visibility and notification rules for related errors, but in some areas it’s a bit weird and confusing. For example, the list of releases for the Sentry project is fairly confusing, as we use git SHAs as release tags in both applications, so there’s no easy way to tell which release belongs to which application. It’s also not clear whether this messes up the “Resolved in the next release” functionality.
Can anyone advise on whether there are ways to make this approach work better, or if there are good reasons not to use it, in spite of the convenience? Thanks.