Broken reconciliation in edge case (202 Pending with different response body object w.r.t. CR spec)

[vicentinileonardo]

A reconciliation deadlock is present in the following scenario.

Scenario

1. CR manifest applied.
2. Resource correctly created.
3. status.id correctly populated.
4. External resource manually delated (web portal).
5. Observe (GET /resources/{id}) -> 404.
6. Create (POST /resources) -> 202 with Operation object (returns fields not related to resource).
7. In this Create (POST) operation, status.id is not updated with new id from the external system since the response is not related to the resource in this 202 case (populateStatusFields() is called but no fields are populated due to the response).
8. Subsequent Observe will perform get operation and not findby since status.id is present in the CR and RDC will declare that the get operation can be used.
9. Observe will fail since it will use the stale id.

Note that his problem happens with:

• 202 Pending with POST returns a response body unrelated to the resource (e.g., Operation instead of Project)
• the endpoint is of the shape: GET /resources/{id} and the id is located in status.id.

In other scenarios like GET /resources/{name} where name is located in the spec of the CR, no problems arise.

Potential solution

Clear status of the CR when setting Pending condition (during a Create operation) so that the following Observe operation will be forced to use the findby action since status.id is not available.
Additional check: this operation should probably be done only if the RestDefinition has a findby action set.
Otherwise it would not make much sense to clear the status. For instance, the GitHub Collaborator resource (which has 202 Pending behaviour) already worked without this reconciliation problem since it uses spec.name for the GET endpoint (GET /resources/{name}).