Making Changes to Decider Code: Versioning and Feature Flags
This section shows how to avoid backwards-incompatible changes to a decider using two methods:
Versioning provides a basic solution.
Versioning with Feature Flags builds on the Versioning solution: No new version of the workflow is introduced, and there is no need to push new code to update the version.
Before you try these solutions, familiarize yourself with the Example Scenario section which explains the causes and effects of backwards-incompatible decider changes.
The Replay Process and Code Changes
When an AWS Flow Framework for Java decider worker executes a decision task, it first must rebuild the current state of the execution before it can add steps to it. The decider does this using a process called replay.
The replay process re-executes the decider code from the beginning, while
simultaneously going through the history of events that have already occurred. Going
through the event history allows the framework to react to signals or task
completion and unblock Promise objects in the code.
When the framework executes the decider code, it assigns an ID to each scheduled task
(an activity, Lambda function, timer, child workflow, or outgoing signal) by
incrementing a counter. The framework communicates this ID to Amazon SWF, and adds the ID
to history events, such as ActivityTaskCompleted.
For the replay process to succeed, it is important for the decider code to be
deterministic, and to schedule the same tasks in the same order for every decision
in every workflow execution. If you don't adhere to this requirement, the framework
might, for example, fail to match the ID in an ActivityTaskCompleted
event to an existing Promise object.
