diff --git a/docs/odata-protocol/odata-protocol.html b/docs/odata-protocol/odata-protocol.html
index 23bf75df..fc967e90 100644
--- a/docs/odata-protocol/odata-protocol.html
+++ b/docs/odata-protocol/odata-protocol.html
@@ -937,6 +937,7 @@
batch request is used to request whether, upon encountering a request within the batch that returns an error, the service return the error for that request and continue processing additional requests within the batch (if specified with an implicit or explicit value of true
), or rather stop further processing (if specified with an explicit value of false
). The syntax of the continue-on-error
preference is defined in OData-ABNF.
The continue-on-error
preference can also be used on a delta update, set-based update, or set-based delete to request that the service continue attempting to process changes after receiving an error.
+If the service encounters any errors processing the request and returns a successful response code, then it MUST include a Preference-Applied
response header containing the continue-on-error
preference with an explicit value of true
.
A service MAY specify support for the continue-on-error
preference using an annotation with term Capabilities.BatchContinueOnErrorSupported
, see OData-VocCap.
The continue-on-error
preference SHOULD NOT be applied to individual requests within a batch.
Note: The continue-on-error
preference was named odata.continue-on-error
in OData version 4.0. Services that support the continue-on-error
preference SHOULD also support odata.continue-on-error
for OData 4.0 clients and clients SHOULD use odata.continue-on-error
for compatibility with OData 4.0 services.
@@ -2595,7 +2596,7 @@ Core.ContentID
term defined in OData-VocCore. Services that respond with 200 OK
SHOULD annotate the entities in the response using the same Core.ContentID
value as specified in the request.
Services SHOULD advertise support for updating a collection using a delta payload through the DeltaUpdateSupported
property of the Capabilities.UpdateRestrictions
term, and SHOULD advertise support for returning the Core.ContentID
through the ContentIDSupported
property of the Capabilities.DeepUpdateSupport
term, both defined in OData-VocCap.
The response, if requested, is a delta payload, in the same structure and order as the request payload, representing the applied changes.
-If the continue-on-error
preference has been specified and any errors occur in processing the changes, then a delta response MUST be returned regardless of the return
preference and MUST contain at least the failed changes. The service represents failed changes in the delta response as follows:
+If the client requests continue-on-error
behavior and the service encounters any errors while processing the request, then it MUST either fail the entire request without applying any changes or include a Preference-Applied
header in the response indicating that the continue-on-error
preference has been applied. In this case, the delta response payload MUST be returned regardless of the return
preference and MUST contain at least the failed changes. The service represents failed changes in the delta response as follows:
- Failed deletes in the request MUST be represented in the response as either entities or entity references, annotated with the term
Core.DataModificationException
, see OData-VocCore. If the deleted entity specified a reason of deleted
, the value of failedOperation
MUST be delete
, otherwise unlink
.
- Failed inserts within the request MUST be represented in the response as deleted entities annotated with the term
Core.DataModificationException
with a failedOperation
value of insert
.
diff --git a/docs/odata-protocol/odata-protocol.md b/docs/odata-protocol/odata-protocol.md
index cdea8128..a6b9a2c0 100644
--- a/docs/odata-protocol/odata-protocol.md
+++ b/docs/odata-protocol/odata-protocol.md
@@ -1328,6 +1328,8 @@ The `continue-on-error` preference can also be used on a
[set-based delete](#DeleteMembersofaCollection) to request that the service
continue attempting to process changes after receiving an error.
+If the service encounters any errors processing the request and returns a successful response code, then it MUST include a [`Preference-Applied`](#HeaderPreferenceApplied) response header containing the `continue-on-error` preference with an explicit value of `true`.
+
A service MAY specify support for the `continue-on-error` preference
using an annotation with term
[`Capabilities.BatchContinueOnErrorSupported`](https://github.com/oasis-tcs/odata-vocabularies/blob/main/vocabularies/Org.OData.Capabilities.V1.md#BatchContinueOnErrorSupported),
@@ -5018,8 +5020,7 @@ term, both defined in [OData-VocCap](#ODataVocCap).
The response, if requested, is a delta payload, in the same structure
and order as the request payload, representing the applied changes.
-If the [`continue-on-error`](#Preferencecontinueonerrorodatacontinueonerror) preference has been specified and any errors
-occur in processing the changes, then a delta response MUST be returned
+If the client requests `continue-on-error` behavior and the service encounters any errors while processing the request, then it MUST either fail the entire request without applying any changes or include a [`Preference-Applied`](#HeaderPreferenceApplied) header in the response indicating that the [`continue-on-error`](#Preferencecontinueonerrorodatacontinueonerror) preference has been applied. In this case, the delta response payload MUST be returned
regardless of the [`return`](#Preferencereturnrepresentationandreturnminimal)
preference and MUST contain at least the failed changes. The service
represents failed changes in the delta response as follows:
diff --git a/odata-protocol/11.4 Data Modification.md b/odata-protocol/11.4 Data Modification.md
index 21dab668..6b97d7fb 100644
--- a/odata-protocol/11.4 Data Modification.md
+++ b/odata-protocol/11.4 Data Modification.md
@@ -1043,8 +1043,7 @@ term, both defined in [OData-VocCap](#ODataVocCap).
The response, if requested, is a delta payload, in the same structure
and order as the request payload, representing the applied changes.
-If the [`continue-on-error`](#Preferencecontinueonerrorodatacontinueonerror) preference has been specified and any errors
-occur in processing the changes, then a delta response MUST be returned
+If the client requests `continue-on-error` behavior and the service encounters any errors while processing the request, then it MUST either fail the entire request without applying any changes or include a [`Preference-Applied`](#HeaderPreferenceApplied) header in the response indicating that the [`continue-on-error`](#Preferencecontinueonerrorodatacontinueonerror) preference has been applied. In this case, the delta response payload MUST be returned
regardless of the [`return`](#Preferencereturnrepresentationandreturnminimal)
preference and MUST contain at least the failed changes. The service
represents failed changes in the delta response as follows:
diff --git a/odata-protocol/8 Header Fields.md b/odata-protocol/8 Header Fields.md
index 0e926a09..21b45ed2 100644
--- a/odata-protocol/8 Header Fields.md
+++ b/odata-protocol/8 Header Fields.md
@@ -439,6 +439,8 @@ The `continue-on-error` preference can also be used on a
[set-based delete](#DeleteMembersofaCollection) to request that the service
continue attempting to process changes after receiving an error.
+If the service encounters any errors processing the request and returns a successful response code, then it MUST include a [`Preference-Applied`](#HeaderPreferenceApplied) response header containing the `continue-on-error` preference with an explicit value of `true`.
+
A service MAY specify support for the `continue-on-error` preference
using an annotation with term
[`Capabilities.BatchContinueOnErrorSupported`](https://github.com/oasis-tcs/odata-vocabularies/blob/main/vocabularies/Org.OData.Capabilities.V1.md#BatchContinueOnErrorSupported),