Specify level for sentry enrichments about apollo-link-sentry HOT 3 CLOSED

After using this for a while, i found the use of setTransaction to be a complete semantic mismatch. I am using routes as transactions for now and turned it off. I am starting to think this option makes little sense at all, given that requests can happen concurrently.

Setting setFingerprint has a similar issue when concurrent requests are involved, it randomly split some errors I had that were unrelated to the current queries. Again, concurrency makes the results totally unpredictable. That said, including it on errors seems sensible, perhaps the only sensible option.

I do like the conditional includes for breadcrumbs. Data volume and size do play a role here, it makes sense to surface as much as possible when errors happen and just have minimal info in other cases.

My proposal to go ahead would be to:

• turn off setTransaction by default, perhaps deprecate it
• add on-error as the new default for setFingerprint
• add on-error to options within attachBreadcrumbs, perhaps also as default for some.

from apollo-link-sentry.

Thanks for both of your efforts in improving this package.

With regards to setTransaction, I agree that it should be disabled by default. To give a little context, when I was writing this package, the app I was writing it for had no concurrent requests. Or maybe it did, but it never happened that two requests failed. Anyway, I do still think the option is useful for the scenario in which I applied it to. We'll want to reference this discussion in the docs, once we change the default.

I think updating the options with an on-error makes sense, but I'm not too comfortable with the notation yet. I will think about this some more tomorrow or Wednesday.

from apollo-link-sentry.

I think I'm asking for the same thing in issue #301 as this issue is asking for, right?

from apollo-link-sentry.