The invisible bug that could break trust in a visual builder

We recently found one of those bugs users may never fully see—but immediately feel.

Under a very specific timing condition, an inactive view could wake up and create two internal generations during what should have been a single loading transaction.

The visible symptoms could be subtle:

• Layers updating twice

• State becoming inconsistent

• Changes feeling delayed or unpredictable

• The wrong view potentially receiving an update

• Undo and redo becoming harder to trust

The issue only appeared during repeated view hibernation and restoration, which made it difficult to reproduce consistently. After several rounds of debugging, we traced it to two separate risks.

First, a view’s load event could start its own request while an automatic wake-up transaction was already in progress. That created a “ghost” generation before the view was fully ready.

Second, the same response could arrive through multiple internal communication paths and needed a stronger guarantee that it could only be accepted once.

We’ve now added two protections which will be released in the next update:

• One wake-up transaction can create only one valid generation.

• One response identity can only trigger one canonical update.

We also expanded the validation suite to repeatedly test:

• Inactive view restoration

• Page and view isolation

• Layers synchronization

• Duplicate responses

• Stale response rejection

• Missing-root recovery

• Repeated hibernation cycles

• Stress across multiple views

• Memory and audit boundaries

The new build is now going through two fully independent browser runs.

We’re not moving forward based on “it worked once.” Every repeated cycle needs to pass before the normal testing flow reopens.

For a visual builder, speed matters—but predictability matters more.

What breaks your trust in a builder fastest: broken undo, unreliable saving, delayed updates, or changes appearing in the wrong place?