Actions
Bug #22160
openIdempotent container request 'Committed' state
Story points:
-
Description
An operation to update a container request from "Uncommitted" to "Committed" failed with the error "cannot go to Committed from Final state". This doesn't make sense because it shouldn't have gotten into "Committed" state.
Here's my best guess as to what happened.
- The container request was created in "Uncommitted" state like normal.
- The container request was updated to "Committed" in the database
- The request reused a container, so it flips over to "Final"
- The response never makes it back to the client
- The client eventually retries the request, and gets back an a 422 error because updating the state from "Final" to "Committed" is not allowed
- The workflow fails
This seems like a pretty low-frequency error (I don't know if we've ever seen it before) but we could tweak the API server behavior so that an update containing the state of "Committed" that doesn't result in changes to any other fields is accepted and it returns the record back in "Final" state. From the client's perspective this looks exactly like what happens when you update to "Committed" and immediately get back a record in "Final" because of container reuse.
Actions