Hacker News Reader

Comment by JackHopkins | Hacker News Reader

Cool! why is it crucial to keep old versions of code, and what are the risks of running outdated code?

If don't keep old code around, you are forced to either drop pending requests that started on them, or try and replay them on the updated code, which can't be known to be safe. So it's better to keep it around, but this brings in a new set of infra and security challenges, eg where will it run, what will it cost, will it have a vulnerable dependency, etc

Can't you replay pending requests? How can you mitigate the issue of differing side effects generated by the new / old versions?

also would be great to see a deep comparison with Temporal and AWS Func

Are there any aspects in particular that would be of interest?

I'd love a deep technical comparison, but it would also be great to understand if Restate is better than Temporal for specific use cases and vice versa. When someone should choose one of them over another

if you replay the request on the new version then you might encounter new steps that don't match what you have in the journal. temporal users know this pain well...

Rolling a task over to a new version should be "safe" in that you can detect conflicts and roll back if the sequence of calls does not match the old version.

For a post about "solving" durable execution I would expect both a scale-to-zero way to keep older versions around indeterminately - I guess the Lambda based approach does qualify - and a safe and controlled way to upgrade task versions iff the execution history is compatible.

How do you imagine detection of conflicts working?

Each execution by design has a record of all calls with side-effects, with input and output.

If you replay history up to the newest call and all calls are identical, that specific execution instance is compatible with the new code and can be upgraded. If not it should be rolled back, and you can either deploy a fixed version of the code with backwards compatibility, or delete executions that can not be upgraded.

Backwards compatible code can be written as

  if (workflowVersion() >= FIX_VERSION) new_way() else old_way()

There should be two ways to get the version for backwards compatibility: workflowVersion() is replayed and can change between side effect calls, e.g executions will use the old retry logic until they reach the current point in time, when they will switch over to the new one.

originalWorkflowVersion() is constant, e.g. all executions that started before NEW_TAX_RULE will keep using the old tax rules for all calculations.

Reply on news.ycombinator.com