We are using the browser Javascript SDK. We have an issue in that errors created in different JS modules are grouped together based on the fact that Sentry only seems to consider the filename from stack frames instead of the whole file path.
We have a setup where we have a number of modules for abstracting backend API calls, the folder structure looks somewhat like this:
/api/user/index.ts
/api/products/index.ts
/api/categories/index.ts
…
Note that all modules are named index.ts, however they are located in different folders, which is a common pattern with ES6 modules. Creating an error in one of those modules results in a stack trace like this, which is also visible in the Sentry event:
* `webpack-internal:///./src/core/utils/error/BaseError.ts` in `BaseError` at line `36:21`
* `webpack-internal:///./src/core/api/Platform/errors.ts` in `_createSuper/<` at line `18:411`
* `webpack-internal:///./src/core/api/Platform/errors.ts` in `ApiError` at line `35:20`
* `webpack-internal:///./src/core/api/Platform/errors.ts` in `toApiError` at line `55:25`
* `webpack-internal:///./src/core/api/Cart/index.ts` in `_callee2$/<` at line `91:93`
Note the last frame that indicates the source location of the error and that it holds the full path which would allow to differentiate between the individual modules. However when looking at the Sentry grouping algorithm, the filename is completely ignored, which leads to all errors from all modules being grouped together:
Long story short, is this behaviour really expected? I can’t wrap my mind around the fact that the algorithm assumes that all files in a codebase would have unique names. And if that is the case what would you suggest as alternative? We have different messages on each error here, so a workaround could be to change fingerprint on the client-side for these kind of errors to consider the message first. But I’m not confident that the same issue wouldn’t pop up in some other part of the codebase.
Thanks for your help,
Sascha