Responses to partially successful atomicity groups or mass updates

[HeikoTheissen]

If a service implements atomicity with isolation level "read uncommitted", and an atomicity group (or equivalently, a changeset) contains a successful and a failed request, must the corresponding responses both have failure status? This means that responses to an atomicity group cannot be streamed to the client.

Or is the client obliged to treat a success response like a failure if it comes from an atomicity group that also contains failed responses? This means that clients may receive success messages from an atomicity group as part of a streamed response, but must treat them as "provisional", because a failure message may come later in the same atomicity group. So clients must implement a rollback mechanism when interpreting the responses.

The same question applies to mass updates without continue-on-error preference: OData-Protocol, section 11.4.11.1 says:

If the continue-on-error preference has not been applied, and the service is unable to apply all of the changes in the request, then it MUST return an error response and MUST NOT apply any of the changes specified in the request payload.

For services that stream their responses, "returning an error" means producing an in-stream error. By then, clients may already have received parts of the response.

OData-Protocol, section 11.5.5.1 speaks of 4xx status codes in two places. (There may be other such places in the spec.) This should be rephrased to "client error", which can mean either a 4xx status code or an in-stream error following a success status code.

[ralfhandl]

For Multipart Batch Responses this problem does not exist because the client never sees the individual response codes:

• When a request within a change set fails, the change set response is not represented using the multipart/mixed media type. Instead, a single response, using the application/http media type, is returned that applies to all requests in the change set and MUST be a valid OData error response.

For a JSON Batch Response the client sees the individual response codes, and each response may have its "natural" response code. It is the client's duty to look at all response codes and determine if the atomicity group as a whole succeeded or failed:

If any response within an atomicity group returns a failure code, all requests within that atomicity group are considered failed, regardless of their individual returned status code.

JSON Batch Responses can be streamed request by request, and clients must implement a rollback mechanism when interpreting the responses.

Multipart Batch Responses can be streamed on the top level.

Collection update responses without continue-on-error cannot be streamed.

[mikepizzo]

From 2026-3-11:

Hubert comments that requests without dependencies are sent asynchronously and the results sent back to the client. This does have the ability for the clients to know what would have succeeded if other things didn't fail.

Mike comments that it is rather unfriendly to the client to tell them things succeeded and then force them to go back and fix things up. We don't have the atomicity groups in the response, meaning that a general component couldn't apply the changes without also being provided the request (we currently try to have the responses be self-describing).

In Multipart, there is a single error returned for the changeset. Mike would like the behavior to be the same regardless of the format. In the Microsoft .NET libraries, the format is chosen at the end; the service serializing the results calls the same APIs regardless the format.

Mike also notes that the issue is only for things within an atomicity group. We assume that atomicity groups are relatively small, and already have extra handling -- caching the response of a (presumably relatively small) set of statements until they have all succeeded, or one failed, doesn't seem a significant burden on the service (especially since they have to do the rollback anyway in case of failure). We typically opt to put the burden on the service, rather than clients.

Current wording seems pretty clear that it is the client's responsibility to ignore changes within an atomicity group that has failures even if their individual status code says succeeded:
"If any response within an atomicity group returns a failure code, all requests within that atomicity group are considered failed, regardless of their individual returned status code. The service MAY return 424 Failed Dependency for statements within an atomicity group that fail or are not attempted due to other failures within the same atomicity group."

Summary:

1. For updating a collection using a delta payload, we say, "If the continue-on-error preference has not been applied, and the service is unable to apply all of the changes in the request, then it MUST return an error response and MUST NOT apply any of the changes specified in the request payload."

We take this to mean that, before the result code is returned, all changes must be applied. The service may return an instream error when serializing, but that does not affect the outcome of the statement.

2. For JSON Batch, current wording is pretty clear that the status code for an individual statement may be a success even if the result was ultimately rolled back due to a separate error of a result in the same atomicity group. This puts the burden on the client to handle the exception case, even though the result doesn't contain enough information to know which statements were part of which atomicity groups.

[HeikoTheissen]

Contrary to what we said in TC 2026-03-11, OData-JSON, section 19.6 states:

If the corresponding request object contains the atomicityGroup name/value pair, it MUST also be present in the response object with the same value.

So the response is self-contained w.r.t. atomicity groups.

[HeikoTheissen]

Current wording seems pretty clear that it is the client's responsibility to ignore changes within an atomicity group that has failures even if their individual status code says succeeded

The SAP implementations return only one error response for the first failed request in this case.

[mikepizzo]

From 2026-3-18: We seem to have pretty clearly considered, and documented, the scenario where, to allow the service to stream even in the presence of atomicity groups, the client has to fix up results. Servers may already implement this behavior, so clients need to be prepared to handle that scenario.

Heiko will check with SAP to see what the client behavior/expectation is around responses returning success within a failed atomicity group.

[HeikoTheissen]

Heiko will check with SAP to see what the client behavior/expectation is around responses returning success within a failed atomicity group.

SAP clients can deal with that.