havremunken
commented
3 years ago For completeness - since not everyone will want to join gitpod, I have extracted the necessary ingredients - the controller and the template - to reproduce this into gists.
Controller: https://gist.github.com/havremunken/1825b2cc016246c888f2318b5dd681ba
Template: https://gist.github.com/havremunken/5345483faf32c1adf0e1935440ce8936
maxfierke
Hi there,
Been discussing this on the #e-concurrency Discord channel, thanks to NullVoxPopuli for helping me create a reproduction outside of my machine.
https://gitpod.io#snapshot/12c4d18c-67f6-400e-8b87-1deef339ee0a
The above is a snapshot of an Ember app that reproduces the problem. Everything relevant is in the application controller and application template. This is a simpified version of code from my own app - minimum I could get that shows the problem.
When the app is running, type two characters into the input field. Then delete both using two delete keystrokes - it needs to be two separate events, as each change to the input starts the updateFilter task. If the second delete happens within 250ms (or increase the DEBOUNCE_MS const), the "early return" from the task without yielding anything will leave the task in an eternal isRunning state. Well, not eternal, if you change the value of the input box, our adventure will begin again.
If you uncomment either of the yields in the isBlank block, the problem does NOT occur.
My ignorant attempt at summarizing the requirements for the issue to surface:
If a restartableTask is restarted while running, and the next incarnation exits without yielding anything, the restartableTask will never get out of the isRunning state by itself. Restarting the task again will of course get it out of this state, but the same problem can be reproduced again and again.
The issue has been observed at least by both NullVoxPopuli and myself at the above linked gitpod.
This happens at least in ember-concurrency 2.0.3. It should be possible to test other versions with the gitpod as well.