Making Changes to Decider Code: Versioning and Feature Flags

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.

Javascript is disabled or is unavailable in your browser.

To use the AWS Documentation, Javascript must be enabled. Please refer to your browser's
Help pages for instructions.