Add lint for protecting people from accidental infinite loops / infinite revalidation errors

[NullVoxPopuli]

Coming out of:

• Infinite loop with ember-data query and ember-concurrency NullVoxPopuli/ember-resources#340
• and Should all action handlers have an implicit await Promise.resolve()? emberjs/rfcs#769

I think we should add a lint rule in certain places known to cause issues with infinite looping

For example, in ember-concurrency tasks, if you don't yield Promise.resolve() or await Promise.resolve() (depending on your ember-concurrency syntax), you'll get the infinite revalidation error (or infinite loop).

This only happens when using concurrency tasks as derived data, such as what ember-resources encourages.

But concurrency tasks aren't the only place where this can happen -- could be in plain functions, helpers, or modifiers as well. Esp as emberjs/rfcs#756 and emberjs/rfcs#757 are implemented.

Maybe it's something we need to work with the typed-ember folks to figure out, because some of this depends on how stuff is used in the template.
Like, eslint can't possible know if a function is going to be a helper or modifier

[NullVoxPopuli]

cc @dfreeman @chriskrycho ?

[NullVoxPopuli]

I think maybe this could only be possible as a type-aware lint rule, and only for types of tracked-data which are not @tracked properties (as, to TS, they are just their value).

[velrest]

Hi @NullVoxPopuli, Is this still ongoing or is this not really doable? We are still running into this occasionally when doing maintenance (ember/data 4 and reactiveweb). Especially for people who have never encountered this before, the github issue NullVoxPopuli/ember-resources#340 is not really easy to find if the problem occurs with trackedFunction and not ember-resources. Should i open a pr in reactive-web to add a note somewhere or do you plan on still implementing a linting solution?

[NullVoxPopuli]

I would love a lint, but i don't how to do it, specifically.
I could do a less than perfect 'best effort' attempt, ofc. There is an easy thing to look for, assignment. But i think it'd only be doable in gjs/gts, because the lists need to, best they can, analyze the reactive pulling on data

While ember-resources would benefit from some lints, the backtracking rerendering error isn't caused by them, it'd be the same if folks were using getters (resources and trackedFunction are kinda like getters)

Now, if you want to open issues and cross link everything for SEO purposes, i think that's a good idea. 🎉

[velrest]

I'll do that 👌 . I think for me part of the confusion is that most of the issues related to this are about direct (in the sense that the dev added an assignment call) assignment in tracked context which is bad design and i think by now, most people know and understand this. What in our team sometimes still pops up is something like this example:

data = trackedFunction(async () => {
  const data = await this.store.findAll('users')
  return data.entries
})

As you wrote in your issue in ember-resources, this seems like its something on ember-data's side. Maybe we can add a linting rule for this?