EEZ Studio SetVariable: Plan for Sequential Writes and Partial Failure

A SetVariable action containing several assignments can look like one indivisible update on an EEZ Studio Flow diagram. Its entry list is not necessarily a transaction. In the inspected implementation, assignments are evaluated and applied in order, so a later failure can leave earlier writes in place.

The SetVariable documentation describes multiple variable/value entries. The pinned implementation loops through those entries, evaluates each destination and source, and immediately calls assignValue. An evaluation failure returns from the function; there is no rollback of earlier entries in this function.

This is a source-level conclusion for framework commit dc9af2d5004201d6c31273a4c4fcfe27fc20c234 in standard EEZ Flow. Verify the actual runtime used with the project. The EEZ Studio v0.29.0 editor reference alone does not identify every exported framework version or the behavior of an external native setter.

A swap exposes sequential evaluation

Start with application variables a = 1 and b = 2. Configure one SetVariable action with the first entry assigning a from b and the second assigning b from a. Sequential evaluation makes the first entry set a to 2. The second then reads the updated a, so both values become 2 under the ordinary variable semantics of this example.

If the intended operation is a swap, preserve the original a in an explicit temporary before overwriting it. The diagram may contain one SetVariable component, but that visual grouping does not give its expressions simultaneous evaluation.

This small example is useful because it tests ordering without depending on an error. It also explains a subtler problem: a later calculation can accidentally use a new value when the designer intended every calculation to use the old configuration.

Partial failure is a separate test

Consider an update with three entries. If the first succeeds and the second fails during destination or value evaluation, the source path returns before the third. The first write has already occurred. An error output or diagnostic message does not, by itself, undo it.

Build a diagnostic case using a runtime failure mechanism that is known and supported in the selected project. Do not use an expression rejected by the editor and call that a partial-runtime-update test. Observe the destination values after the failure, not merely whether an error connector fired.

Repeat with the failure at different positions. An error before any assignment and an error after two assignments leave different states. The recovery design should account for the actual point of failure rather than treating every failed component execution as though nothing happened.

Validate candidates before publishing them

For a configuration update, first compute candidate values in separate temporary variables or a separate application-owned structure. Validate their relationships before assigning the live configuration. For example, a lower limit and upper limit need a joint consistency check, not merely two individually well-typed assignments.

This staging pattern reduces the chance of partially publishing an invalid configuration. It does not automatically make the final publication atomic. If other code can observe the live fields independently, or if native setters have side effects, that publication boundary needs its own design.

Where the application already has a native configuration API that validates and commits a complete request, a Flow adapter can call that API with an explicit success or failure result. Such an API is an application facility to implement and verify; it is not a transactional mode supplied by SetVariable.

Distinguish restoration from reversal of side effects

Restoring old variable values may repair an in-memory state, but it does not necessarily reverse everything triggered by the earlier assignments. A native setter could send a command, write storage or initiate another operation. This function's assignment loop does not establish the rollback semantics of those external effects.

Before adding a compensating SetVariable action, classify each destination. Is it a simple application variable, a derived value, a native property or an interface with side effects? A compensation plan must follow the destination's actual contract.

Avoid promising “all changes are undone” merely because the visible controls show their previous values. The recovery evidence should include the system state that matters, not only the display.

Make the update contract reviewable

For each multi-entry action, record the intended evaluation order, which expressions depend on earlier writes, and what state is acceptable after a supported failure. If no partial state is acceptable, redesign the update around a validation and commit boundary appropriate to the application.

Test the successful path, the swap-style ordering probe and at least one controlled failure after an earlier successful write. Keep those experiments free of real external side effects until their behavior is understood.

No Flow execution or rollback experiment was performed for this article. The source-derived finding is narrow but consequential: a SetVariable entry list performs ordered writes, and the inspected function does not roll them back on a later evaluation failure. Treat that as an update contract to design around, not an implicit transaction.