Failed to serialize object for property 'pause_durations'

[dartasen]

Package

Sentry.Maui

.NET Flavor

.NET

.NET Version

9.0.2

OS

Android

SDK Version

5.1.1

Self-Hosted Sentry Version

No response

Steps to Reproduce

?

Might be related but we're setting the following MSBuild property :
<JsonSerializerIsReflectionEnabledByDefault>false</JsonSerializerIsReflectionEnabledByDefault>

But since I can see some Json Source Generation Context involved inside of Sentry, I guess it might be an oversight

Expected Result

No error

Actual Result

Error: Failed to serialize object for property 'pause_durations'. Original depth: 3, current depth: 3
System.InvalidOperationException: JsonTypeInfo metadata for type 'System.Object[]' was not provided by TypeInfoResolver of type 'Sentry.Internal.Extensions.SentryJsonContext'. If using source generation, ensure that all root types passed to the serializer have been annotated with 'JsonSerializableAttribute', along with any types that might be serialized polymorphically.
   at System.Text.Json.ThrowHelper.ThrowInvalidOperationException_NoMetadataForType(Type type, IJsonTypeInfoResolver resolver)
   at System.Text.Json.JsonSerializer.GetTypeInfo(JsonSerializerContext context, Type inputType)
   at System.Text.Json.JsonSerializer.SerializeToUtf8Bytes(Object value, Type inputType, JsonSerializerContext context)
   at Sentry.Internal.Extensions.JsonExtensions.<InternalSerializeToUtf8Bytes>g__AotSerializeToUtf8Bytes|40_0(<>c__DisplayClass40_0& )
   at Sentry.Internal.Extensions.JsonExtensions.InternalSerializeToUtf8Bytes(Object value)
   at Sentry.Internal.Extensions.JsonExtensions.WriteDynamicValue(Utf8JsonWriter writer, Object value, IDiagnosticLogger logger)
   at Sentry.Internal.Extensions.JsonExtensions.WriteDynamic(Utf8JsonWriter writer, String propertyName, Object value, IDiagnosticLogger logger)

My sentry init code :

    private static MauiAppBuilder ConfigureSentry(this MauiAppBuilder builder)
    {
        return builder.UseSentry(options =>
          {
              options.Dsn = [REDACTED]
              options.Release = AppConstants.APP_VERSION;

#if DEBUG
              // Use debug mode if you want to see what the SDK is doing.
              // Debug messages are written to stdout with Console.Writeline,
              // and are viewable in your IDE's debug console or with 'adb logcat', etc.
              // This option is not recommended when deploying your application.  
              options.Debug = true;
              options.Environment = "debug";
              options.DiagnosticLevel = SentryLevel.Info;

              // Set TracesSampleRate to 1.0 to capture 100% of transactions for tracing.
              options.TracesSampleRate = 1.0;
#else
             options.Debug = false;
             options.DiagnosticLevel = SentryLevel.Warning;
             options.Environment = "production";

             // Set TracesSampleRate to 1.0 to capture 100% of transactions for tracing.
             options.TracesSampleRate = 0.25;
#endif

              // This option is recommended. It enables Sentry's "Release Health" feature.
              options.AutoSessionTracking = true;

              // Enabling this option is recommended for client applications only. It ensures all threads use the same global scope.
              options.IsGlobalModeEnabled = true;

              options.StackTraceMode = StackTraceMode.Enhanced;

              options.AttachScreenshot = true;
          });
    }

[aritchie]

Hi @dartasen Thanks for reporting this issue.

Can you let me know the following:

1. false does it work if you remove this or set it to true?
2. Are you using <PublishAot>? If so, what's the value?
3. Are you able to provide a small, reproducible sample?

Also, what platform(s) are you seeing this issue?

[dartasen]

Hello @aritchie

1. It does indeed work if I turn it back on
2. Not sure to understand the question
3. Could see if I can produce one if it can help. Not sure when this kind of serialization is triggered by Sentry though, is it periodic ?

My MAUI app does use NativeAOT on iOS but did not receive any report from any Apple user yet, only some on Android for now.

[aritchie]

@dartasen I didn't quote the <PublishAot> in question 2. In any case, you answered it anyhow.

I think we've got enough info here to work with. Thank you for the report and feedback.

[jamescrosswell]

It looks false is the default.

I'm wondering how/where WriteDynamic is being used to try to serialise that property though. Our own serialisers do this (no reflection required):

sentry-dotnet/src/Sentry/Internal/MemoryInfo.cs

Lines 99 to 105 in 5fab09e

	writer.WritePropertyName("pause_durations");
	writer.WriteStartArray();
	foreach (var duration in PauseDurations)
	{
	writer.WriteNumberValue(duration.TotalMilliseconds);
	}
	writer.WriteEndArray();

It'd be good to see the full stack trace so we could see what was calling Sentry.Internal.Extensions.JsonExtensions.WriteDynamic.

[dartasen]

@jamescrosswell It's indeed false by default when publishing, but I also have it turned off even in DEBUG to make it easier to spot issues with System.Text.Json serialization in early development stages.

Issue is printed as an error inside the Output tab on VS, but I don't have any Sentry report on the dashboard.
So that's all I've got, as in stacktraces for now. Is there a way to collect more data ?

I've appended my sentry init code to the original message if that can help. I see that we're using StackTraceMode.Enhanced that uses Ben.Demystifier under the hood, could it be related ?

[jamescrosswell]

@dartasen it could yes. Ben.Demystifier relies on reflection so we don't use it when trimming or AOT compilation is enabled:

sentry-dotnet/src/Sentry/SentryClient.cs

Lines 233 to 237 in 8abc13e

	if (!AotHelper.IsTrimmed)
	{
	// Attempt to demystify exceptions before adding them as breadcrumbs.
	e.Demystify();
	}

When publishing on iOS then, enhanced stack frames won't be used (AOT compilation is required on iOS).

Android only supports partial AOT compilation (I think specific methods and code paths were targeted to optimise startup times, but everything else is still JIT - @aritchie probably knows more about this).

It's pretty hard to tell without being able to reproduce the problem though - mostly wild speculation. If we can reproduce it, we should be able to work out what's going on.