Show HN: Restate – low-latency durable workflows for JavaScript/Java, in Rust

Re:Show HN: Restate – low-latency durable workflows for Java... by fire_lake on Wednesday June 12, 2024 @12:23PM (#40659863)

This assumes that the APIs work this way?

What if the first call is to get a resource that expires and then the last call fails?

Now it will retry but with an expired resource (first call is saved).

[ Parent | on HN ]

Re:Show HN: Restate – low-latency durable workflows for Java... by p10jkle on Wednesday June 12, 2024 @12:34PM (#40660035)

I think you would need to validate the response from the first call before determining it to be a success?

[ Parent | on HN ]

Re:Show HN: Restate – low-latency durable workflows for Java... by fire_lake on Wednesday June 12, 2024 @03:13PM (#40661812)

First call: fetch a widget

Success! Your widget expires in 30 seconds

Second call: use widget

Failure! For some reason or another

Ok, so restart the flow…

First call: fetch a widget

Cached! Receive the same widget again

Second call: use widget

Failure! widget has now expired

[ Parent | on HN ]

Re:Show HN: Restate – low-latency durable workflows for Java... by p10jkle on Wednesday June 12, 2024 @04:02PM (#40662416)

Ah I see what you mean. In this case the handler should complete with a terminal error - we weren't able to finish the task in time. Of course, many types of errors and timeouts are valid application-level results, not transient infrastructure issues. And sadly, tight timeouts push transient issues into application-level issues, and this is unavoidable, I think

[ Parent | on HN ]