Unexpected error when using records

[TimSon777]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Hello! We have a record like this

public record TemplateRequirementsValidationRequestDto(
	[property: DataMember(Name = "templateRequirements")]
	string TemplateRequirements,
	[property: DataMember(Name = "mailingKind")]
	MailingKind MailingKind,
	[property: DataMember(Name = "recipientsFileInternalId")]
	int? RecipientsFileInternalId);

which we use in the endpoint like this

[HttpPost("do-smth")]
public async Task<JsonResult> DoSmth(
	[FromBody] TemplateRequirementsValidationRequestDto request)
{
    // ...
}

this code works stably and has been live for a whole year

Our application has several instances (2) with a balancer that proxies requests to one of these instances. And one day we saw this error:

InvalidOperationException: No property found that maps to constructor parameter 'RecipientsFileInternalId' for type 'Services.Core.TemplateRequirementsValidationRequestDto'. Validation requires that each bound parameter of a record type's primary constructor must have a property to read the value.

We did a little research and found out that the error occurred only on one instance, while the other instance worked without this error. Therefore, half of the requests completed successfully. After restarting the problematic instance, the errors disappeared

This error was introduced into the framework in this PR with the addition of support for records and appears in this place

The tests are not very informative in this particular place - so it was not possible to understand why this error occurred, perhaps there is a race somewhere or something else. Help me figure it out!

Expected Behavior

The error does not occur at random times

Steps To Reproduce

No steps

Exceptions (if any)

InvalidOperationException: No property found that maps to constructor parameter 'RecipientsFileInternalId' for type 'Services.Core.TemplateRequirementsValidationRequestDto'. Validation requires that each bound parameter of a record type's primary constructor must have a property to read the value.

.NET Version

8.0.x

Anything else?

No response

[captainsafia]

@TimSon777 Thanks for filing this issue and taking the time to put in some leg work with the investigation.

We did a little research and found out that the error occurred only on one instance, while the other instance worked without this error. Therefore, half of the requests completed successfully. After restarting the problematic instance, the errors disappeared

Has the error emerged again on the same instance after the restart? Has it never manifested on the other instance?

[TimSon777]

Hello! We have diagnosed this error only once on one instance. After restarting this instance, the error did not appear again. Our instances themselves are periodically restarted (when we roll out new code, for example), and everything always works fine in them. The endpoint, which responded with an error, has not changed for a year. It looks like a very rare race. I will add a detail: the error started immediately after the launch of the problematic instance and ended after its restart

[gearsetdave]

We get this error now and again. I'd say maybe twice a year on average, although we've hit it three times so far this year. I actually fixed the error message, because before it didn't tell you the parameter name (it told you the type name). Our last occurrence of it was last month. When it happens, the instance is broken because these things get cached.

I'm looking into it again and was browsing through the original PR for some clues. If it's possible for the mapping to have something missing, needing this exception to be thrown, maybe someone knew of a situation where it might possibly happen... I didn't find anything yet, apart from seeing this issue was linked to it :)

It's one of those things that's rare and difficult to reason about, so it keeps getting put on our back burner.

[mikeronayne]

We have diagnosed this error only once on one instance. After restarting this instance, the error did not appear again

+1 for another victim of this