🚨 Important (Alpha) : isEqual Check Removed for Mapping Source Updates — Avoid Updates During Validation Execution

vaibhav · March 11, 2026, 1:11pm

Hi Teams,

We want to highlight an important behavior to be aware of when working with mapping source variables (e.g. co, case_instance, task_instance, local) inside validation callbacks.

What can go wrong? (See attached screenshot)

As shown in the attached screenshot, updating a mapping source (for example via alpha.co.update()) inside a validation flow can lead to a recursive loop involving:

MappingSource.update
AlphaRenderer.onChangeMappingSource
AlphaValidator.validate
Custom validation callbacks

This creates an infinite validation → update → validation cycle, eventually resulting in:

Uncaught RangeError: Maximum call stack size exceeded

Updating any bound mapping source variable inside a validation callback can:

Create circular updates
Re-trigger validations repeatedly
Cause out-of-loop updates that may get missed
Lead to inconsistent component state or side effects

This happens because validations are already part of the reactive update cycle — mutating the model from within that same cycle interferes with how updates are propagated.

Risky Example (for illustration)

ap.renderer.validations.add(
    'f8ca6515-0291-485d-80e2-1187a7291c44', // Leaf id
    'invalid-mapping-update', // Validation key name
    (leafInstance) => {
        alpha.co.update('mappingKey', true); // ⚠️ Problematic inside validation

        return {
            valid: leafInstance.value === true,
            error:
                leafInstance.value === true
                    ? undefined
                    : {
                          message: 'Value should be true',
                          name: 'invalid-mapping-update',
                      },
        };
    },
);

The same risk applies if you update any of these mapping sources inside validation:
'co', 'case_instance', 'task_instance', 'local'

Recommended practice

Do NOT update mapping source variables inside validation callbacks.

Instead:

Treat validations as pure checks (read data → return valid/error).
Perform model updates outside validation.

Note

This issue initially came through support request(NPFRBT-883), following which we introduced an isEqual check as a safeguard to prevent infinite update loops. This check compared the existing mapping source value with the new value before emitting update events.

However, we later discovered that this approach could also block valid update scenarios (for example, array mutation + update patterns) and prevent expected mapping_source_updated events from firing. Because of these side effects, the isEqual check will get removed in the 49th LTS release and 1.0.7 Current release .

Until we design and roll out a more robust long-term solution, please avoid updating mapping source variables inside validation callbacks

If you have a use case where you must update data during validation, please share it — this will help us design a safer and more predictable solution.

Regards,
Alpha Team