Context

This issue occurs due to a computation being rendered before a dependency of that computation is updated – during the same render pass.

In this case:

    const fileQueueService = this.owner.lookup(
      'service:file-queue',
    ) as FileQueueService;

    await render(
      <template>
        <ul>
          {{! `fileQueueService.files` is a computation of all files in all queues }}
          {{#each fileQueueService.files as |file|}}
            <li>
              {{file.name}}
            </li>
          {{/each}}
        </ul>

        {{! The `fileQueue` helper calls `fileQueueService.findOrCreate` which may create a new queue }}
        {{! Thus invalidating `fileQueueService.files` }}
        {{#let (fileQueue) as |queue|}}
          <label>
            <input type='file' {{queue.selectFile}} hidden />
            Select File
          </label>
        {{/let}}
      </template>,
    );

This is sometimes called a "backtracking re-render". Further reading:

• [Glimmer 2] "Backtracking re-render" is now an assertion emberjs/ember.js#13948

Partial fix

A workaround to prevent this issue for the DEFAULT_QUEUE is to create it early, before the render pass.

However, with a named queue this would need to be done by consumers in their own app code. A demonstration of this has been added as a test.

Probably, some documentation should be updated to warn about this.

Considerations

This is only a partial fix. As a breaking change we might want to restrict the fileQueue helper to only being able find queues, and not create them.

That would mean users should create any named queues explicity in their own app code outside of rendering. This is a minor limitation, but I think it might be a better design since it suggests using autotracking in a more conventional way. Users would still be able to create dynamically named queues if they wanted, thought that's probably rare.

Partially fixes #1085