captureMessage random grouping logic

[simonmcl]

Platform

iOS

Environment

Production

Installed

Swift Package Manager

Version

8.39.0

Xcode Version

16.1

Did it work on previous versions?

not sure

Steps to Reproduce

1. setup sentry to monitor crash reports, as per setup instructions
2. add a few sentry.captureMessage("") calls with different strings throughout app

Expected Result

Messages should be grouped on the sentry dashboard based on title, so that we can see the count of each individual string

Actual Result

Grouping appears random. I am recording 3 strings at the moment, and at first all 3 grouped up inside 1 "issue" on the dashboard, which is titled the first message to be received. This is incredibly confusing/frustrating as you have to click into each item to see what that actual message was.

After I made a slight change to the UI, the messages now split into a second issue. So I have, for example, all messages from 1.1.0 going to one issues, and all messages from 1.1.1+ going to a second issue.

While debugging with your team on discord, they asked me to check a few things and try a few things. First they suggested that I add my own fingerprints, which the captureMessage function doesn't take. So I would have to add logic to the beforeSend, but the team on discord tells me theres no enum (or similar) to check whether the event is of type message or not. I complained that this is convoluted and they suggested I disable stacktraces which by default are used as fingerprints. I can't do this as I need those for crash reports. When I suggested that its extremely odd and not at all what I would have expected the default behaviour to be, that messages are using stacktraces like this, they suggested I open a ticket here

So:

• I would have expected that the only fingerprint used by messages would default to just the message
• It would be helpful, at least as a workaround or perhaps for more advanced cases, if captureMessage accepted a fingerprint param to override it
• I would have expected some easy way to identify messages inside the beforeSend without relying on heuristics like "its probably going to be all events with priority low"
• I don't see a reason why messages would be defaulting to using stacktraces, this seems like a bad idea

Please also note that there are a dozen or so other similar complaints in the discord at the moment about this grouping logic

Are you willing to submit a PR?

If it was swift only, possibly, this likely needs backend/dashboard work which I'm not able to do

[philipphofmann]

We group errors by error and not by their stacktrace, so also grouping captureMessage events by message seems legit. On the other hand, we already have this behavior for multiple versions, and most users haven't complained, so it seems to work for them. We can only make this change with a major update. We're going to discuss if changing the default behavior makes sense and then update the issue accordingly.

But you don't have to wait for a major update. You can create your own SentryEvent with a custom fingerprint rule to achieve what you want

let event = Event(level: .info)
let message = "Your message 1"
event.message = SentryMessage(formatted: message)
event.fingerprint = [message]
SentrySDK.capture(event: event)

It's the same as the client does, but it adds a custom fingerprint to it.

sentry-cocoa/Sources/Sentry/SentryClient.m

Lines 176 to 181 in 6e2994b

	- (SentryId *)captureMessage:(NSString *)message withScope:(SentryScope *)scope
	{
	SentryEvent *event = [[SentryEvent alloc] initWithLevel:kSentryLevelInfo];
	event.message = [[SentryMessage alloc] initWithFormatted:message];
	return [self sendEvent:event withScope:scope alwaysAttachStacktrace:NO];
	}

[simonmcl]

@philipphofmann I understand changing default behaviour might affect others, the work around I suggested, adding the ability to supply a fingerprint on captureMessage() directly might be a happy middle ground as at least it becomes a bit more obvious.

Looking at it again, my particular issue might be because these 3 captureMessages are coming from the same function in a single viewController. Meaning they would all have the same stackTrace. Perhaps this isn't a common case and other users doing this across various files aren't seeing the same behaviour, and are in fact seeing the behaviour I want. Its possible most wouldn't even notice such a change. But that would require a lot of digging to be able to say confidently