We tend to get lots of situations, and it seems to have gotten worse since we started using Sentry, where either errors we want separate (different error text) get combined, or errors we want combined (same error txt) are split up. I suspect this is due to sentry weighing in some way more towards the call stacks involved, rather than the text of the error (which would be our preferred default).
We should investigate and see if we can come up with some way to fix this. This might involved some code changes (maybe around adding a few more @_transparent functions to tweak what call stacks we are generating), or it could jsut be coming up with a set of recommendations for how to configure the error merging in Sentry project on the website (where there are lots of options for how to tweak that behaviour).
We tend to get lots of situations, and it seems to have gotten worse since we started using Sentry, where either errors we want separate (different error text) get combined, or errors we want combined (same error txt) are split up. I suspect this is due to sentry weighing in some way more towards the call stacks involved, rather than the text of the error (which would be our preferred default).
We should investigate and see if we can come up with some way to fix this. This might involved some code changes (maybe around adding a few more
@_transparentfunctions to tweak what call stacks we are generating), or it could jsut be coming up with a set of recommendations for how to configure the error merging in Sentry project on the website (where there are lots of options for how to tweak that behaviour).