Subject: Re: [scim] SCIM: Questions regarding Error handling for Bulk operations

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Mon, 20 Aug 2018 19:11:53 +0000

Hi Jena,

Best option for getting clarification on SCIM spec is to reach out to the WG mailing list: [email-masked]. Many more eyes will see it there.

As to your specific question, I am actually not 100% sure. Re-reading the spec seems to be a bit ambiguous there and I haven’t actually implemented bulk myself. I believe the answer to both scenarios is returning 200 responses with operation responses of 409 for the failed.

Phil, others, do you have a better answer? Have we clarified this somewhere else in the doc that I am missing?

Cheers,
Morteza

From: "Jena, Jayadeba" <[email-masked]>
Date: Friday, August 17, 2018 at 5:32 PM
To: "[email-masked]" <[email-masked]>, Chuck Mortimore <[email-masked]>
Subject: SCIM: Questions regarding Error handling for Bulk operations

Hi,

I’m from PayPal and trying to understand the SCIM bulk specification and have questions around the error handling with “failOnError” not specified in the request. As an example, I was reading through the section (https://tools.ietf.org/html/rfc7644#section-3.7.1) - which says that we need to return the error code 409 when the circular dependency couldn’t be resolved by the server. The behavior of the bulk server wrt is not clear to me when we have the “FailOnError” flag is not specified. Please help clarify if the following behavior is correct and as per the specification.

  *   Scenario1: When there’s a bulk request body with 2 items, failOnErrors flag is not specified in the request- The server while processing the bulk requests, discovers circular dependency that it couldn’t resolve, what would be the bulk response? Should the bulk server return a top level 409 response or a 200 response with operation response for each failed items (i.e 2 operation responses with 409 as the code for each).
  *   Scenario2: When there’s a bulk request body with 3 items, failOnErrors flag is not specified in the request- The server while processing the bulk requests, discovers circular dependency that it couldn’t resolve for the first 2 items, while the 3rd items could be processed successfully, what would be the bulk response? Should it be a  200 response with operation response for each failed items (i.e 2 operation responses with 409 as the code for each) and then it also contains the successful response for the 3rd item

Thanks,
Jayadeba

---

From: Phil Hunt <[email-masked]>
Date: Mon, 20 Aug 2018 13:40:15 -0700

Morteza/Jena,

The IDCS (Identity Cloud Service) bulk endpoint returns an overall 200 and then 409 for each resource operation that failed (due to cycle or any other reason) and a 200/201 for those that succeed.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Aug 20, 2018, at 12:11 PM, Morteza Ansari (moransar) <moransar=[email-masked]> wrote:
> 
> Hi Jena,
>  
> Best option for getting clarification on SCIM spec is to reach out to the WG mailing list: [email-masked] <mailto:[email-masked]>. Many more eyes will see it there.
>  
> From: "Jena, Jayadeba" <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Chuck Mortimore <[email-masked] <mailto:[email-masked]>>
> I’m from PayPal and trying to understand the SCIM bulk specification and have questions around the error handling with “failOnError” not specified in the request. As an example, I was reading through the section (https://tools.ietf.org/html/rfc7644#section-3.7.1 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7644-23section-2D3.7.1&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=pyJbcSIML-m5QRPAfMRPW1D5vOwW3y_KWQo_pX0bJh0&s=rd-Tvkl4RlzRIcibzydGY6X7AR9lv3FOPuTCB6MNgZ8&e=>) - which says that we need to return the error code 409 when the circular dependency couldn’t be resolved by the server. The behavior of the bulk server wrt is not clear to me when we have the “FailOnError” flag is not specified. Please help clarify if the following behavior is correct and as per the specification.
>  
> Scenario1: When there’s a bulk request body with 2 items, failOnErrors flag is not specified in the request- The server while processing the bulk requests, discovers circular dependency that it couldn’t resolve, what would be the bulk response? Should the bulk server return a top level 409 response or a 200 response with operation response for each failed items (i.e 2 operation responses with 409 as the code for each).
> Scenario2: When there’s a bulk request body with 3 items, failOnErrors flag is not specified in the request- The server while processing the bulk requests, discovers circular dependency that it couldn’t resolve for the first 2 items, while the 3rd items could be processed successfully, what would be the bulk response? Should it be a  200 response with operation response for each failed items (i.e 2 operation responses with 409 as the code for each) and then it also contains the successful response for the 3rd item
>  
> Thanks,
> Jayadeba
>  
> _______________________________________________
> scim mailing list
> [email-masked] <mailto:[email-masked]>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=pyJbcSIML-m5QRPAfMRPW1D5vOwW3y_KWQo_pX0bJh0&s=Qd2Np4bHIUk6wz2YbFfR1mQ9xfEPtgGxHm40luqoUjg&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=pyJbcSIML-m5QRPAfMRPW1D5vOwW3y_KWQo_pX0bJh0&s=Qd2Np4bHIUk6wz2YbFfR1mQ9xfEPtgGxHm40luqoUjg&e=>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 20 Aug 2018 23:34:24 -0700

Jayadeba,

I don’t believe I see an issue here. Keep in mind the following from Sec 3.7:

> failOnErrors
>       An integer specifying the number of errors that the service
>       provider will accept before the operation is terminated and an
>       error response is returned.  OPTIONAL in a request.  Not valid in
>       a response.

In the processing rules:
>    The service provider MUST continue performing as many changes as
>    possible and disregard partial failures.  The client MAY override
>    this behavior by specifying a value for the "failOnErrors" attribute.
>    The "failOnErrors" attribute defines the number of errors that the
>    service provider should accept before failing the remaining
>    operations returning the response.

Thus, unless a fatal error (e.g. like a syntax/parsing error) occurs, a 200 response is almost always expected with any errors embedded in the transaction - even if all transactions fail.

In each of your scenarios, I would expect 200 responses with individual transactions indicating correct success/failure as if they were their own separate HTTP request - e.g. so you would issue 409 for the specific transaction status.

Phil

> On Aug 20, 2018, at 7:09 PM, Jena, Jayadeba <[email-masked]> wrote:
> 
> Thanks Phil, Morteza! Appreciate your quick response in clarifying this.
>  
> It would be great if the spec can be updated to clearly describe the behavior of the bulk server wrt error handling in partial success cases so anyone implementing the bulk API later doesn’t come across the same set of questions. It would be great to add some canonical examples as well.
>  
> Thanks again!
>  
> Jayadeba
>  
> From: Phil Hunt <[email-masked]>
> Date: Monday, August 20, 2018 at 1:40 PM
> To: "Morteza Ansari (moransar)" <moransar=[email-masked]>
> Cc: "Jena, Jayadeba" <[email-masked]>, Chuck Mortimore <[email-masked]>, "[email-masked]" <[email-masked]>
> Subject: Re: [scim] SCIM: Questions regarding Error handling for Bulk operations
>  
> Morteza/Jena, 
>  
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=IW0pK2S_tDZmsBAMNhx8eLn8fo8aY4TrxLKHLiFPzes&s=XAhIpuMi7adufIojCfe2ULfCBG2aTKK_Go3jH5zgrw0&e=>
> [email-masked] <mailto:[email-masked]>
> 
> 
>> On Aug 20, 2018, at 12:11 PM, Morteza Ansari (moransar) <moransar=[email-masked] <mailto:moransar=[email-masked]>> wrote:
>>  
>> Hi Jena,
>>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 22 Aug 2018 14:49:15 -0700

>  The service provider response MUST include the result of all
>    processed operations.  

I see the poor wording. “processed” could be interpreted in some circles as successful items only. 

The intent was to be all records processed whether successful or not. Without a response clients would not know the outcome of the “missing” transactions and would be indeterminate.

Phil

> On Aug 21, 2018, at 12:01 AM, Jena, Jayadeba <[email-masked]> wrote:
> 
> Phil, 
>  
> The processing rules behavior is clear but I felt that the bulk response handling for the partial failure cases is not super clear (or ambiguous) from the perspective of a implementor- Whether the bulk response should contain all failed items or the failed items should be omitted in the response. This is how I and few of my colleagues at PayPal reading the spec felt so I reached out to you for clarification. We felt like there’s no authoritative statement.
>  
> Please feel free to consider this as an exception and ignore my request to add to the documentation.
>  
> Thanks for the details clarification! It helped.
>  
> Thanks,
> Jayadeba
>  
> Date: Monday, August 20, 2018 at 11:34 PM
> To: "Jena, Jayadeba" <[email-masked]>
> Cc: "Morteza Ansari (moransar)" <moransar=[email-masked]>, Chuck Mortimore <[email-masked]>, "[email-masked]" <[email-masked]>
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=kkqUZJQyDycxKrJh7C0yXIK455QjHVPkc8lWvzE77aA&s=7ulncV_Y7oQ9atfau_mCbWEWya8IWZsNoq-7PG_OlhE&e=>
>> On Aug 20, 2018, at 7:09 PM, Jena, Jayadeba <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> From: Phil Hunt <[email-masked] <mailto:[email-masked]>>
>> To: "Morteza Ansari (moransar)" <moransar=[email-masked] <mailto:moransar=[email-masked]>>
>> Cc: "Jena, Jayadeba" <[email-masked] <mailto:[email-masked]>>, Chuck Mortimore <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>