A technical reviewer in another time zone may not answer before the process preparing a product draft has stopped. That should not force the sales team to start the task again. The useful requirement is to preserve what was prepared, what decision is outstanding and which reply would allow the next step to begin.

AWS announced general availability of the Lambda Durable Execution SDK for Go on October 15. It provides checkpoints, waits and callback integration for multi-step work, including workflows that pause for human review. For teams already building such applications, this is a way to separate a long business wait from active program execution. It is not a reason to replace a satisfactory manual review queue with a new software stack.

The distinction becomes important when an AI-assisted handoff spans days: completed preparation can remain available without repeatedly generating the draft or keeping a polling loop alive merely to ask whether somebody has replied.

Keep the draft that the reviewer was asked to approve

A process that loops until a reply arrives has to survive restarts and preserve its own progress. A durable wait records the suspension point and completed results so the execution can continue after an external event. A user interface can accurately show that the task is waiting even though no continuous calculation is taking place during the interval.

AWS documents recovery through checkpoint replay. The code passes through the execution from the beginning, but completed checkpointed work is skipped and its stored results are used. That does not mean every business operation should be performed again. Developers need to design which operations are durable steps rather than assume any existing sequence becomes recoverable by adding a continue button.

For an overseas team reviewing a Chinese supplier's product response, the saved material should identify the requirement, the product version and the draft actually sent for confirmation. Regenerating a slightly different draft when the reply arrives changes the text under review. Attaching the old approval to that new text would be a business error even if the technical workflow resumed without interruption.

The saved result need not be an unlimited copy of every conversation. Keep the information needed to identify the pending decision and its relevant evidence, under the application's existing access and retention arrangements. The engineering objective is continuity of the specific task, not accumulation of unrelated customer material.

A callback carries a reply, not an interpretation

Receiving a message such as “approved” is only useful if the workflow can associate it with a particular task and version. It may approve a configuration description, authorise further checking or permit a later business action. Those meanings should not be inferred from a callback arriving. The application must know what decision it requested and what the reviewer actually supplied.

This is related to checking actual wording before closing a quotation comment. A completed discussion state is not enough to identify the final buyer-facing commitment. At a workflow's resume point, compare the reply, the reviewed draft and the text about to be used. They should refer to the same decision, not merely the same customer name.

Conditions can change while the task waits. Stock, delivery assumptions or product details may require a current read before the next action. Completed research can remain useful while a time-sensitive condition expires. Define those expiry conditions for the actual workflow rather than choosing between repeating everything and trusting everything indefinitely.

External effects require their own controls too. A workflow's progress record does not make every email, record update or other service call universally exactly-once. If an external action has an uncertain outcome, reconcile it using the receiving system's available evidence. Restarting the whole workflow is not a reliable way to decide whether that action already happened.

Testing should include replies that arrive late, arrive twice, refer to an outdated draft or never arrive before an agreed deadline. The Go SDK announcement describes local workflow testing with durabletest. The business owner still needs to define whether each of those cases should resume work, remain waiting or request human attention. A testing tool cannot supply the decision policy.

The final design can be simple from the reviewer's perspective: one identifiable draft, one explicit decision and a clear place to see whether the task is waiting or continuing. Technical persistence does its part when the reply returns to the work it was meant to decide, rather than to a freshly recreated approximation of that work.

Sources