Live data from Hacker News

Solving durable execution's immutability problem

restate.dev

1–10 of 29 posts

Re: Solving durable execution's immutability problem

#5

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

Re: Solving durable execution's immutability problem

#6
post #5

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?

Re: Solving durable execution's immutability problem

#8
post #5

Earlier quoted context omitted.

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

Re: Solving durable execution's immutability problem

#9
post #5

Earlier quoted context omitted.

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?

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...
Post reply on HN