I was reading the part of the spec which talks about what should happen if a deprovision request is received whilst an async provision is in progress:
If a Service Broker accepts the request to delete a Service Instance during the process of it being
created, then it MUST have the net effect of halting the current creation process and deleting any
resources associated with the Service Instance. If the request to create the Service Instance is
asynchronous, then its last_operation response SHOULD return an HTTP status code of 200, a state
value of failed and a description that indicates the create failed due to a concurrent delete request.
This suggests that, if the broker supports this and doesn't return a 422 Concurrency Error, then a call to GET /v2/service_instances/:instance_id/last_operation should return "state": "failed".
However, what happens if the broker wants to handle the deprovision request asynchronously? Assuming the broker does not return an operation ID, then how should a platform understand when the deprovision has completed if GET /v2/service_instances/:instance_id/last_operation should return "state": "failed"?
I was reading the part of the spec which talks about what should happen if a deprovision request is received whilst an async provision is in progress:
This suggests that, if the broker supports this and doesn't return a 422 Concurrency Error, then a call to
GET /v2/service_instances/:instance_id/last_operationshould return"state": "failed".However, what happens if the broker wants to handle the deprovision request asynchronously? Assuming the broker does not return an
operationID, then how should a platform understand when the deprovision has completed ifGET /v2/service_instances/:instance_id/last_operationshould return"state": "failed"?