In client-side Javascript, we load a script that does logging for analytics purposes. That script makes calls to the analytics server that sometimes fail with UnhandledRejection: "error". According to the analytics service, this is expected behavior.
Since the calls are made from deep within the 3rd party library, we can’t wrap them in try-catch directly. Sentry makes it seem like the errors are coming from our website, since we load the 3rd party library directly, so adding the URL to the blacklist isn’t possible.
UnhandledRejection: "error" is generic enough that I don’t want to add that string to our ignoreErrors array, either.
Is there a way to filter based on what the promise that had an unhandled rejection was trying to do?
First of all, unhandled promise rejections shouldn’t be best practice, especially not if you just do Promise.reject("error") they should at least do something like Promise.reject(new Error("error")) than we could at least get a stack trace out of the Promise. Just as a feedback you can forward to them
Now to your issue, I agree, adding it to ignoreErrors seems to drastic.
What you could try is to use the beforeSend callback and check if you can just identify this error somehow and return null in this case. Then the event will be discarded.
beforeSend also receives a hint as second argument, maybe there is enough information in there to identify this unhandled promise.