EEZ Studio Data Inputs: Detect a New Trigger Reusing Old Values

A newly triggered EEZ Studio action can run using a data value left over from its previous execution. This is not necessarily a race in the native code. Standard Flow retains data inputs, so “a required input has a value” and “this request received a fresh value” are different conditions.

The EEZ Flow execution documentation explains retained data inputs and the normal clearing of sequence inputs. In the pinned framework readiness code, isComponentReadyToRun checks input availability; resetSequenceInputs normally clears sequence inputs and includes a special Output-action exception.

This discussion uses framework commit dc9af2d5004201d6c31273a4c4fcfe27fc20c234 as a separate implementation reference from EEZ Studio v0.29.0. Check the exported runtime and component-specific behavior. It is not a universal rule for every optional input, disconnected connector or Flow Lite component.

Reproduce stale data with a harmless consumer

Create a diagnostic consumer with required data inputs named requestId and amount, plus the sequence trigger used by the design. First supply request A and amount 10, then trigger it. Record both values at the consumer.

Next supply request B but deliberately delay the new amount. Trigger the consumer again. If the old amount remains available, the consumer can observe B together with 10. Every required input has a value, yet the pair does not necessarily belong to one coherent request.

This is a proposed test, not an executed trace. Use a log or a diagnostic label rather than a real command. The important observation is the combination of values at the consuming action, not merely the order in which the upstream widgets changed visually.

Availability is weaker than freshness

Retained inputs are useful. A configuration value need not be resent every time a new sequence pulse uses it. The problem appears when the application assumes all inputs represent a new batch, while the graph only requires that each input contain something.

Classify each input as persistent configuration, current state or per-request data. A persistent threshold paired with a new measurement can be intentional. A new account identifier paired with an old requested amount is usually not. The same retention mechanism can support either outcome depending on the application's contract.

Do not solve every retained-input issue by trying to clear values indiscriminately. That can break intentionally persistent settings or interact with component-specific readiness rules. First establish which values must advance together and what event authorizes their use.

Give coherent requests an identity

One approach is to publish the related fields as one application-owned request record, including a request identifier. The consumer receives a single accepted request rather than reconstructing a batch from independently arriving fields. Verify the representation and copy semantics of that record in the selected project.

If separate inputs are necessary, attach matching generation identifiers and validate them before performing the operation. A consumer can reject or defer a mismatched pair rather than treating “both present” as sufficient. This validation is application logic; Flow's ordinary availability check does not supply it automatically.

Keep configuration generations distinct from request identities when their lifetimes differ. A new request may intentionally use the current configuration, but that relationship should be named. Overloading one counter to mean both can create false mismatches or hide a configuration update.

Publish the trigger at a deliberate boundary

A producer should establish the accepted request data before issuing the sequence signal that authorizes consumption. However, “write fields, then trigger” is only a useful design if the actual writers and scheduling arrangement preserve that relationship.

If native threads, independent callbacks or separate Flow branches can update fields, inspect their synchronization and ownership. The general Flow queue description does not create an atomic cross-thread snapshot. A correct-looking visual wire order cannot replace the native integration's data-publication contract.

For a purely Flow-owned diagnostic, deliberately vary the arrival order. Send data before the trigger, the trigger before one field, and two request updates close together. Observe the consumed identities and values. These cases make the freshness assumption explicit without requiring a complex device workload.

Test reuse and lifecycle separately

Run the diagnostic twice in the same Flow state, then repeat across the actual lifecycle boundary used by the product. Reusing an active component and creating a new Flow instance can have different available values. Do not infer one from the other.

Also include the action's optional-input configuration in the test record. A component that is intentionally allowed to run without a particular input requires a different acceptance rule from one that waits for all mandatory data. The special handling of some actions means a broad “all inputs reset after execution” explanation is particularly unsafe.

No Flow test was executed here. A useful acceptance record shows not just that the consumer ran, but that every consumed field belonged to the intended request or documented persistent configuration. That closes the gap between an available value and a fresh, coherent input set.