Lambda Durable Functions is a powerful new feature, but its checkpoint + replay model has a few gotchas.

Here are five to watch out for.

Non-deterministic code

The biggest gotcha is when the code is not deterministic. That is, it might do something different during replay.

Remember, when a durable execution is replayed, the handler code is executed from the start. So the code must behave exactly the same given the same input.

If you use random numbers, or timestamps to make branching decisions. Then during a replay, the code might do something different! This is why, you should capture the branching decision in a step instead. So, during a replay, the previous decision is retrieved from the checkpoint logs.

Side-effecting code outside step

You should avoid causing side effects (e.g. updating databases, calling external APIs, sending emails) outside steps.

This is to avoid causing the same side effects again during a replay.

Mutate closure variables

Avoid mutating variables that are captured in the closure, inside a step. Because these mutations will be skipped during a replay, leading to non-deterministic behaviour.

Dynamic step names

Avoid dynamic names for durable operations.

During replay, you get a different step name to the original invocation, so the system won't be able to fetch the stored result from the checkpoint.

Child context results > 256kb are reconstructed during replay

You are working with child contexts whenever you use the "runInChildContext", "parallel" or "map" operations. If a child context’s result is greater than 256kb, then it’s not stored directly. During a replay, its result is instead reconstructed by executing the context's operations again.

This is mentioned in small print in the official documentation.

Take the following code as example:

If its result is less than 256kb, then it's stored in the database. On replay, the result is fetched and the whole child context is skipped.

However, if the result is bigger than 256kb, then it's not saved. On replay, the child context, and therefore this block of code, will be executed again.

The previous durable operations ("step-1" and "step-2") will be skipped. But any non-durable code will be executed again.

This interplays with the previous gotchas. For example, during a replay, side-effecting actions outside of a step might be executed again if the encompassing child context is re-evaluated.

​

Ok, that's five gotchas of working with Lambda Durable Functions.

Personally, I'm very excited about Durable Functions and it's something that we're covering in the latest Production-Ready Serverless workshop.

In week 3 of the workshop, you will implement the same order processing workflow using an event-driven approach, vs. Step Functions, vs. using Durable Functions. So we can discuss the pros & cons of each approach.

It's still not too late to join us. Registration closes this Sunday, 18th January.