Closed buchanae closed 6 years ago
Sorry, I created these issues quickly as notes during the C&W call so I wouldn't forget about them.
The question here is what (if any) guarantees a TES client has from the server while creating tasks. In particular, if a client creates a task and immediately starts a polling loop, is the server guaranteed to return a state for the created task (i.e. HTTP 200 not 404)?
In a large scale system, it could be more difficult to implement that guarantee (e.g. if your distributed database is eventually consistent).
Gotcha. Yeah this is one of those things where I see why it's valuable as part of a spec but also starts bumping into my general sentiment that the more fiddly a spec like this, the less likely people are to implement it.
Agreed. The main goal here is to document "we thought of this and made a decision", even if that decision is "TES makes no guarantees in this aspect".
Closing this because I don't have a good action item for this. The spec shouldn't bother to document all the quirks of distributed systems, and it shouldn't require that implementations be strongly consistent either. I suspect this is not going to be a problem anyway. If it is an issue after people have experience with real TES services for a couple years, we can revisit.
This sounds like something which is going down too detailed a path IMO. What exactly are you thinking of here?