search

ga4gh / task-execution-schemas

Apache License 2.0
80 stars 28 forks source link

Consider spec. of eventual consistency expectations #56

Closed buchanae closed 6 years ago

geoffjentry commented 7 years ago

This sounds like something which is going down too detailed a path IMO. What exactly are you thinking of here?

buchanae commented 7 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).

geoffjentry commented 7 years ago

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.

buchanae commented 7 years ago

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".

buchanae commented 6 years ago

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.