Alex Matchneer

@dsafonov-grid I wrote some tests to reproduce but couldn't get things to break, then I re-read your comment on async observers and when I set the behavior back to old...

I ran into another case of `waitForProperty` hanging indefinitely, even with async observers enabled. ``` @tracked alert: Alert | null = null get modalReady() { return !this.alert; } // in...

Also for posterity I made a PollForProperty that does timeout polling: https://gist.github.com/machty/50be480319857b2513cb8b65f7433d68 I didn't end up needing it but it did solve work as an alternative to waitForProperty.

I'm not sure what to recommend here; I don't think EC is alone in recommending use of cancelTimers, and lots of folk doing custom long-polling solutions are probably using cancelTimers....

I've read this a few times over but I'm still confused as to what the behavior you're seeing is... could you write out some pseudocode or try and explain it...

Nevermind, I understand it and will try and take a look at this today (not sure how intense the refactor would be to fix this)

@mwpastore I agree this should all Just Work but what's the use case for being able to distinguish between the task.last and taskGroup.last?

This issue will be used at an EmberConf Contributor Workshop, so please no one else try and fix in the meantime: For any EmberConf contributors who wants to try and...

@sukima recent versions of e-c don't "throw" cancelation errors, so there's no need to use `didCancel()` here. `didCancel()` only exists for when you treat a performed task like a promise...

Well definitely feel free to explore and experiment, but my hunch is that e-c might not be the library to try and improve the error handling semantics that plague JS...