One or more property types could be found

An error message indicates that one or more property types could not be found. (Captioned by AI)
I’m managing some content in Umbraco V16 and I’m encountering the error shown above. However, I have no idea what might be causing it. The response from the request is also very minimal:

{
    "type": "Error",
    "title": "One or more property types could not be found",
    "status": 404,
    "operationStatus": "PropertyTypeNotFound"
}

I also checked the source code and found the following section where this error could occur:
(https://github.com/umbraco/Umbraco-CMS/blob/5c57d03d6d5c2dc8d3104322e45f454ddd897ffb/src/Umbraco.Core/Services/ContentEditingServiceBase.cs#L353)

        // verify that all property values are defined as property types
        if (propertyValuesAndVariance.Any(pv => propertyTypesByAlias.ContainsKey(pv.PropertyValue.Alias) == false))
        {
            operationStatus = ContentEditingOperationStatus.PropertyTypeNotFound;
            return null;
        }

        // verify that all properties match their respective property type culture and segment variance - i.e. no culture invariant properties that should have been culture variant
        if (propertyValuesAndVariance.Any(pv =>
            {
                IPropertyType propertyType = propertyTypesByAlias[pv.PropertyValue.Alias];
                return (propertyType.VariesByCulture() != pv.VariesByCulture)
                       || (propertyType.VariesBySegment() is false && pv.VariesBySegment);
            }))
        {
            operationStatus = ContentEditingOperationStatus.PropertyTypeNotFound;
            return null;
        }

The challenge is reproducing this in a reliable way that actually triggers useful logging.
What I’ve noticed is that it often happens when populating multiple block list items at once. Could that be related?

So my general question is: does anyone have an idea how I can figure out why this error is occurring?

Greetings,
Joppe

hey joppe,
i got this similar issue i assume u get this issue when handeling event eg: save and publish right?
and the v16 site is deployed somewhere maybe IIS?
again u didnt specify what u did and expected result,
could u try adding:

<modules>
        <remove name="WebDAVModule" />
      </modules>
      <handlers>
	          <remove name="WebDAV" />

        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>

to web.config

Hi Bishal,

Thank you for your response.

What we’ve noticed is that when filling in content on an Umbraco node (with a relatively large number of fields), the above error sometimes occurs. As you rightly pointed out, “again u didn’t specify what u did and expected result” — that’s true, because the error occurs sporadically, and we haven’t found a direct correlation between a specific action and the appearance of the error. This makes it difficult to pinpoint the root cause.

The only pattern we’ve observed is that the error occurs less frequently when we add just one block list item to a content block, compared to when we add two or more. Even this behavior, however, isn’t entirely consistent.

Personally, I would have expected Umbraco to log the mismatch in property types, so that it would be clearer for developers how to resolve these kinds of issues — rather than just returning a plain error response to the client.

Regarding the suggested actions to take: our site is running on Azure, not on IIS, and as far as I understand, the WebDAVModule is an IIS extension, not something that applies to Azure App Service.

As far as I know, removing WebDAV is mainly relevant for enabling all HTTP RESTful request types such as PUT, DELETE, PATCH, etc. To my knowledge, Azure does not block these by default or get in the way in this regard.

That’s why I also have a question about the goal you were trying to achieve by removing WebDAV.
Perhaps I can achieve the same result through a different approach.

If your goal was to prevent 405 (Method Not Allowed) responses, I’m not sure that’s the issue in our case — since a significant number of save operations do succeed, even though they use the same HTTP methods.

Greetings,
Joppe