`CaptureMessage` inconsistency between manual capture and Debug.Log integration

[bitsandfoxes]

The Problem

There are multiple ways to send an event to Sentry i.e.

• Logging Integration automatically captures logs of a certain level
• Unhandled Exceptions
• Manually capturing an exception
• Manually sending a message

These show up in the issue stream but there is inconsistency as to where the title comes from and what ends up as message.

If you look at a trace it looks like Sentry pulls either the title or the message and appends them to each other.

The Cause

With CaptureErrorLogEvents enabled, the SDK will automatically capture Debug.LogError() as error event. With the option to attach the stacktrace to logmessages enabled, the SDK will create and capture a "synthetic" UnityLogErrorException:

sentry-unity/src/Sentry.Unity/Integrations/UnityApplicationLoggingIntegration.cs

Lines 86 to 91 in d43d51b

	if (_options?.AttachStacktrace is true && !string.IsNullOrEmpty(stacktrace))
	{
	var ule = new UnityErrorLogException(message, stacktrace, _options);
	var sentryEvent = new SentryEvent(ule) { Level = SentryLevel.Error };
	_hub.CaptureEvent(sentryEvent);

The stack trace provided by Unity gets parsed during event processing.

sentry-unity/src/Sentry.Unity/Integrations/UnityErrorLogException.cs

Line 40 in d43d51b

public SentryException ToSentryException()

Since we're treating this as an exception we're setting the exception type, so the message shows up like an exception on the issue stream

sentry-unity/src/Sentry.Unity/Integrations/UnityErrorLogException.cs

Line 18 in d43d51b

internal static readonly string ExceptionType = "LogError";

The Proposal

We could just not set the exception type and treat this like any other message. Instead, we can let this be marked solely in the mechanism as we already do

sentry-unity/src/Sentry.Unity/Integrations/UnityErrorLogException.cs

Lines 54 to 58 in d43d51b

	Mechanism = new Mechanism
	{
	Handled = true,
	Type = "unity.log"
	}

[linear]

UNITY-165 `CaptureMessage` inconsistency between manual capture and Debug.Log integration