When should custom fingerprints override Sentry's default grouping instead of tuning server-side rules?
Our team is deciding how to manage issue grouping in Sentry for a growing set of services. We know Sentry groups events primarily by stack trace, with fallbacks to message and exception type, and that we can override this either by setting a custom fingerprint in the SDK (for example in a before-send hook) or by configuring server-side fingerprinting rules i