error.type attribute value of http.server.request.duration metric

[vishweshbankwar]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The value of error.type attribute on http.server.request.duration does not take the status code in to account as per the spec

If response status code was sent or received and status indicates an error according to HTTP span status definition, error.type SHOULD be set to the status code number (represented as a string), an exception type (if thrown) or a component-specific error identifier.

Src link:

aspnetcore/src/Hosting/Hosting/src/Internal/HostingMetrics.cs

Lines 72 to 77 in e497b5a

	// This exception is only present if there is an unhandled exception.
	// An exception caught by ExceptionHandlerMiddleware and DeveloperExceptionMiddleware isn't thrown to here. Instead, those middleware add error.type to custom tags.
	if (exception != null)
	{
	tags.Add("error.type", exception.GetType().FullName);
	}

Expected Behavior

error.type is set to Status Code value as per spec.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

.NET8

Anything else?

No response

[vishweshbankwar]

@JamesNK PTAL

[danmoseley]

@JamesNK we can possibly still take this for GA if necessary.

[JamesNK]

This is not a must-have and can wait.

The missing behavior is error.type should be populated if the server returns a 5xx status code; however, most of the time, a 5xx status code is set from ASP.NET Core error handling. Error handling sets error.type to the exception type name, which takes precedence over the status code. That means it's rare to have a 5xx status code without error.type already having a value.

I think this could wait until .NET 9, and we have a breaking change notification to tell people about the change in behavior between .NET 8 and .NET 9.

@noahfalk @antonfirsov @lmolkova Thoughts?

[noahfalk]

This is not a must-have and can wait.

Sounds fine to me. 👍

[vishweshbankwar]

Thanks for confirming the plan. For .NET6.0 and .NET7.0 we would keep the same behavior as .NET8.0 in order to avoid breaking users moving from .NET6.0/.NET7.0. (slightly deviating from spec). @trask FYI

cc: @alanwest @CodeBlanch @utpilla