Delta<Entity> Path Request unable to serialize in case properties are sent in different order.

[manikantsinghms]

Failing request:

{
"siteProtectionUnits@delta": [
{
"id": "MmI5NWUyZmItNjBlZC00ZmNkLTkxMzQtNWU3MDlkZjY0OGM2XzE=",
"@removed": {
"reason": "changed"
}
}
],
"displayName": "SP Policy 6 Shell 1"
}

Success Request:

{
"siteProtectionUnits@delta": [
{
"@removed": {
"reason": "changed"
},
"id": "MmI5NWUyZmItNjBlZC00ZmNkLTkxMzQtNWU3MDlkZjY0OGM2XzE="
}
],
"displayName": "SP Policy 6 Shell 1"
}

Based on the order of "Id"/"@removed" property, our service is not able to read the payload correctly.

Controller

public class SharePointProtectionPoliciesController : ProtectionControllerBase
{
public async Task Patch([FromRoute] string key, [FromBody] Delta sharePointProtectionPolicy)
{
return await PatchPolicy(key, PolicyType.SharePoint, sharePointProtectionPolicy);
}
}

From the ODATA official documentation we observed that, it's required to have properties in specific order for ordered payload but in other cases nothing is mentioned as such.

We also don't have any specified in out controller to either enable or disable ordered payload support.
However, I get to see "odata.streaming=true" in the response.

Could you please help us understand the issue and how can we fix it.
Thanks in advance.

[manikantsinghms]

@xuzhg @gathogojr @ElizabethOkerio @gathogojr -- Tagging top contributors in hope to get right traction.

[ElizabethOkerio]

@manikantsinghms When odata.streaming=true, OData writes an ordered payload. In an ordered payload, the OData JSON specification requires that the id control information, if present, must immediately follow the @removed control information. Spec reference
.

[manikantsinghms]

@ElizabethOkerio, but client is not sending us "odata.streaming=true" in content-type headers, then why do we expect it to be ordered payload? Why Odata is failing to read the payload correctly?

Is there a configuration to manage it?

"OData writes an ordered payload" this should be applicable for the response only, right?

[ElizabethOkerio]

@manikantsinghms Can you check the request being sent. Content-Type: application/json;metadata=minimal;streaming=true if it has something like this then the response will be ordered. Check this: https://docs.oasis-open.org/odata/odata-json-format/v4.02/csd01/odata-json-format-v4.02-csd01.html#PayloadOrderingConstraints

[manikantsinghms]

Hi @ElizabethOkerio, There is no header "streaming=true"

PATCH https://graph.microsoft.com/v1.0/solutions/backupRestore/sharePointProtectionPolicies/7aa910c1-af61-4b78-b921-a023d5642c1f HTTP/1.1
Host: graph.microsoft.com
FeatureFlag: 00000003
Cache-Control: no-store, no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Microsoft Windows 10.0.22631; en-IN) PowerShell/7.5.2
Authorization: Bearer
SdkVersion: graph-powershell/2.30.0
client-request-id: 407b123e-4c5d-4d63-b859-ded2ca08ec80
Accept-Encoding: gzip, deflate, br
Content-Type: application/json
Content-Length: 226

{
"siteProtectionUnits@delta": [
{
"id": "MmI5NWUyZmItNjBlZC00ZmNkLTkxMzQtNWU3MDlkZjY0OGM2XzE=",
"@removed": {
"reason": "changed"
}
}
],
"displayName": "SP Policy 6 Shell 1"
}

[ElizabethOkerio]

Interesting. Interesting — it looks like OData automatically appends some default media type parameters to the response, even if the client didn’t explicitly request them. Typical defaults include:

odata.metadata=minimal; odata.streaming=true; IEEE754Compatible=false

https://github.com/OData/odata.net/blob/6d4b51258cc8b8d9700bd86bb13639b2f0e1d0e2/src/Microsoft.OData.Core/ODataUtils.cs#L288C9-L288C16

If you need different values, you can override them either by specifying the desired parameters in the client’s Accept header, or on the server side by setting the content type explicitly through the ODataMessageWriterSettings.

[manikantsinghms]

I tried specifying client-headers yet it returns odata.streaming=true.

Additionally, if ODATA itself adds streaming headers, shouldn't this be a documentation bug?

[mikepizzo]

Note that specifying streaming=true in the response payload indicates that the response is ordered. We add that because the library always writes ordered responses. The lack of streaming=true in the request (or explicitly stating streaming=false) tells the service whether the request is ordered.

Regarding the @removed control information:

The Microsoft.OData.Core library today requires that the @removed control information come after the @odata.context (if supplied) and before any other properties or control information.

This requirement follows the protocol for ordered payloads:
"For ordered payloads, the control information removed MUST immediately follow the context control information, if present, otherwise it MUST be the first property in the deleted entity."

By protocol, if the client does not specify odata.streaming=true, then the service should not require this ordering.

However, our code tries to determine whether the json object represents a deleted entity early on (before reading other properties) and, especially since deleted entries can contain other properties (including nested properties/resources) it can be expensive to buffer all of the resource (and nested resources) in memory in order to determine whether or not it contains the @removed control information.

We can look to see if there is a way we can at least cover this case (id before @removed) but will likely not support a completely unordered payload due to the expense.

Do you know how the update payload is being generated? Is it possible to generate it in the correct order (with @removed before any other properties)?

[manikantsinghms]

the payload is getting generated by microsoft.sdk powershell.
We initially opened a bug with them, but they responded saying that they do no support streaming and do not guarantee ordered payload.

[manikantsinghms]

@mikepizzo , Please let me know if this is going to be supported if yes, by when we an expect it be fixed.

Else we can also, we should update the ODATA document that incase of deleted entities, only ordered payload is supported.

[manikantsinghms]

@mikepizzo , could you please provide an update on my queries.

[mikepizzo]

I believe that, following our triage last week, @WanjohiSammy was going to follow up.

This is related to OData/odata.net#3069, which was created by @xuzhg. That PR was put on hold because the initial implementation read/buffered too much of the payload, and the client was able to change the ordering of the properties when generating the request payload.

OData/odata.net#3069 (comment) suggests that we could expand the existing logic that reads all of the control information up to the first property, but that would have to be amended to read all of the control information and key properties up to the first non-control/non-key property in order to determine whether or not this was a deleted resource. That would address this case as well without the performance issues of having to read to the end in search of certain control information.

Let's use OData/odata.net#3069 to track this issue. @marabooy for awareness.

[manikantsinghms]

Adding + @rushikesh ***@***.***>, @diksha ***@***.***>

…

________________________________ From: Michael Pizzo ***@***.***> Sent: Tuesday, September 16, 2025 10:18 PM To: OData/AspNetCoreOData ***@***.***> Cc: Manikant Singh ***@***.***>; Mention ***@***.***> Subject: Re: [OData/AspNetCoreOData] Delta<Entity> Path Request unable to serialize in case properties are sent in different order. (Discussion #1523) I believe that, following our triage last week, @WanjohiSammy<https://github.com/WanjohiSammy> was going to follow up. This is related to OData/odata.net#3069<OData/odata.net#3069>, which was created by @xuzhg<https://github.com/xuzhg>. That PR was put on hold because the initial implementation read/buffered too much of the payload, and the client was able to change the ordering of the properties when generating the request payload. OData/odata.net#3069 (comment)<OData/odata.net#3069 (comment)> suggests that we could expand the existing logic that reads all of the control information up to the first property, but that would have to be amended to read all of the control information and key properties up to the first non-control/non-key property in order to determine whether or not this was a deleted resource. That would address this case as well without the performance issues of having to read to the end in search of certain control information. Let's use OData/odata.net#3069<OData/odata.net#3069> to track this issue. @marabooy<https://github.com/marabooy> for awareness. — Reply to this email directly, view it on GitHub<#1523 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BDKSSEP5FR5VPR4UWC6X53L3TA5NPAVCNFSM6AAAAACFW42ZX2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINBRHA3TSOI>. You are receiving this because you were mentioned.Message ID: ***@***.***>