Race condition in HTTP API for submit/modify

[virtuald]

Assuming you support multiple HTTP clients (I didn't see anything saying you don't), there's a race condition in the HTTP API.

If a client tries to submit a unit using /units/NAME, and someone else does it before they do, then they will not receive any notification that the submission failed. This is because the same endpoint is used for modify and submit, so a modify operation happens instead. However, I don't believe the client is currently told which one happened.

One could try to work around this by checking to see if the unit exists before submitting it, but obviously the race condition is even larger then. Another workaround is inspecting the state of the unit after you submit it to make sure it matches what you think it should be -- but it seems like that shouldn't be necessary.

Ideally, the API should either use different endpoints for modify/submit, or return a status indicating which of the two actions happened.

[jonboulle]

I think this is essentially covered by #851

[bcwaldon]

@virtuald #851 is how we have planned to cover this problem

[virtuald]

Does that mean that the client will be notified whether there is an update/insert then? Or are you separating the operations? It's not clear from the other ticket.

[bcwaldon]

@virtuald The operations will not be separated. The API is declarative, so it is built around the concept of declaring the desired state of the system. If a client actually cares whether or not they ended up created a given unit vs updated it, they can check the status code (201 vs 204). The race condition you described can be prevented by calling PUT with the new desiredState along with the options (or hash of options) you expect the unit to have, essentially acting like a CAS token.

[virtuald]

Aha, the status code is different? That's good enough for me -- should be in the documentation then.

[bcwaldon]

@virtuald If it isn't today, it will be before we finalize the API.

[virtuald]

@bcwaldon The status code in fleet 0.8.0 appears to always be 204 (no content).

[bcwaldon]

@virtuald Ok - would you like to file a bug? PRs accepted, but we are more than happy to address the problem for you.

[virtuald]

Sure, opened at #910.

It's worth noting that the bug I originally opened (this one) is asking for exactly that. :)