Non-deterministic state updates during Ember Octane run loop transitions

Question

When building a repeatable development environment in Ember Octane, the interaction between the run loop and native JavaScript classes introduces inconsistencies. While the run loop aims to batch state changes across modes like actions and render to ensure deterministic updates, the transition from EmberObject to native classes affects how state is tracked.

A specific concern arises when using store.findRecord in Ember Data during repeated development or test cycles. If a record remains cached in the store without an explicit unloadRecord, the freshness of the data may vary depending on whether the run loop has scheduled a sync update before the component attempts to re-render.

How does the run loop guarantee consistent execution order when native class components rely on asynchronous data-driven properties? What are the specific mechanisms to ensure the store state is identical across multiple rapid rebuilds without manually clearing the global cache?

Tasadduq Burney · Answer

Direct answer
The Ember Octane run loop batches state changes into backburner queues (sync actions render afterRender destroy). Native class components use @tracked setters that enqueue render work, preserving order relative to other scheduled callbacks. For store.findRecord, if the record resides in the identity map, the promise resolves synchronously as a microtask with the cached instance; otherwise a network fetch occurs. During rapid live-reload, the app instance and its store is torn down and recreated, clearing the cache automatically. In persistent test suites without proper teardown, shared stores can retain stale records, causing non-deterministic updates.
Likely explanation vs confirmed facts
Non-determinism often stems from cached records persisting across rebuilds or from test code that does not await settled() before asserting on rendered state. Confirmed facts: The run loop queue ordering is deterministic within a single instance; findRecord cache behavior is documented for Ember Data 3x/4x with Octane defaults; app-instance restart clears the identity map.

Always await the findRecord promise before using the returned record in component state or computed properties.
  In tests, call await settled() after triggering async data loads to ensure all run-loop queues, including render, have flushed.
  If the same app instance persists and backend data may have changed, invoke store.unloadRecord(record) or record.reload() before the next findRecord call to bypass the cache.
  Avoid side effects in getters; derive computed state from @tracked properties or explicit methods.

To refine this recommendation, please confirm whether the observed non-determinism occurs during browser live-reload cycles (where the app instance restarts) or within a persistent test suite sharing a global store, and the specific Ember Data version in use.

Non-deterministic state updates during Ember Octane run loop transitions

1 answer

Direct answer

Likely explanation vs confirmed facts

Your perspective belongs here.

0 question comments