Infinite loop/"Maximum call stack size exceeded" with getter/sortBy (with Octane preview blueprint)

[pgengler]

Reproduction: https://github.com/pgengler/octane-preview-app/tree/infinite-loop-computed-property (make sure you use the "infinite-loop-computed-property" branch)

If I have a component that has a getter to return a sorted array:

// app/components/category-picker.js

import Component from '@glimmer/component';

export default class CategoryPickerComponent extends Component {
  get sortedCategories() {
    return this.args.categories.sortBy('name');
  }
  // ...
}

{{!-- app/templates/components/category-picker.hbs --}}
{{#power-select-multiple
    options=this.sortedCategories
    selected=this.selectedCategories
    onchange=this.onchange
  as |category|
}}
  {{category.name}}
{{/power-select-multiple}}

then I get an infinite recursion/"maximum call stack size exceeded" error when passing this.sortedCategories into {{ember-power-select-multiple}}.

If I leave off the sortBy and just return the original array, everything works OK.

In the reproduction app, the index page has two links: "With array .sortBy" (uses .sortBy and will show the error) and "Without array .sortBy" (which just returns the passed array without sorting, and does not have the error).

[runspired]

I suspect the issue here might be that sortBy uses the JS sort function which mutates the array in-place, which likely triggers an invalidation of the array.

Source: https://github.com/emberjs/ember.js/blob/v3.8.0/packages/%40ember/-internals/runtime/lib/mixins/array.js#L1056

[pgengler]

I have a new branch on that repo (https://github.com/pgengler/octane-preview-app/tree/simplified-infinite-loop-computed-property) that simplifies (but also confuses) things. I got rid of any use of ember-data and just have the model hook return a hard-coded array of hashes, which are passed into the component. The sortedCategories getter on the CategoryPicker component reads, but doesn't use, this.args.categories; it then creates a new hard-coded array, calls .sort (native JS sort, not .sortBy) on it, and returns this array (which is then passed into {{power-select-multiple}}, as before. This still has the same problem as the original case ("Maximum call stack size exceeded").

[wagenet]

@pzuraq can give a run down of the core issue here.