-
Notifications
You must be signed in to change notification settings - Fork 401
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
馃悶[BUG]: Angular ErrorHandler not called anymore (regression) #1965
Comments
thanks for the fast response @markwhitfeld ! Update: On further debugging, I found it is worse than I thought. it('this will fail too', async () => {
errorHandler.handleError = jest.fn();
store.dispatch(new ThrowingAction());
expect(errorHandler.handleError).toHaveBeenCalled()
}); I found an additional minor behavior change: it('should work asynchronously', async () => {
/**
* this will now fail because due to the recent error handling change,
* as soon as anything subscribes, ngxs ignores errors. We are blind now. :(
*/
errorHandler.handleError = jest.fn();
store.dispatch(new ThrowingAction());
// expect(errorHandler.handleError).toHaveBeenCalled()
await new Promise((res)=>{
setTimeout(res,10)
}).then(()=>{
expect(errorHandler.handleError).toHaveBeenCalled()
})
}); |
Just a few questions:
Everything should work as expected if you are operating within a PS. The Angular ErrorHandler is in place to catch things that are exceptional, and not part of normal program flow. |
Right now, I am only aware of this issue inside of tests, however I have not tested behavior inside Angular app at all yet. |
Hi @markwhitfeld , here's the information you were requesting! Your assumptions were pretty much correct.
About your P.S.: Agreed. I'm not describing regular program flow here, just things that I found during debugging and things that we sometimes rely on e.g. when unit testing correct erroring behavior. In such a case a now-async handling will make tests fail that previously worked based on the assumption of synchronous error delegation. |
@jbjhjm I was the author of those changes and definitely this seems to be a regression. But this is a "stochastic" regression. This means the actual behavior we have right now is valid at runtime (and as you also confirmed), but the breaking change exists which leads to a regression. The root issue is that the runtime behavior differs from the unit testing behavior. This is caused by zone.js. It's NOT behaving in the same way as it behaves at runtime. At runtime Angular forks the zone and provides the |
@arturovt sounds logical. Right now, error reporting "mode" will be switched off as soon as ANY subscriber is being added. Assuming for most users the previous error handling solution was perfectly fine, I believe a hybrid, configurable approach is most appropriate. As far as I understand the source code, a simple configurable flag toggling the check for existing subscribers on or off would restore the known "classic" behavior. |
It's not transparent. All of those "hacks" are related to NGXS execution strategy which handles actions outside of the Angular zone by default, meaning that failed tasks are not caught by Angular's zone. This is why we had to subscribe manually to the dispatch result and call error handler manually. We haven't come up to the most transparent approach for now. |
@markwhitfeld I don't think we have to revert the implementation we pair-programmed. We could add a config flag (e.g., |
just updated our repo to use ngxs 3.8.0. I found that one reported detail is incorrect: I thought of updating test implementations... Don't see a well working solution despite configurable error handling or a specific error-handling mode for test environments. |
Affected Package
@ngxs/storeIs this a regression?
Yes, used to work in 3.7.4
(likely introduced in 3.7.6)
97% sure its caused by this change: https://github.com/ngxs/store/pull/1927/files
Description
Errors thrown in Action handlers are not propagated to Angular ErrorHandler anymore.
This is breaking several of our unit tests and also hides errors that else would be propagated to ng ErrorHandler, followed by our Error Management system connecting to that.
With #1927 I found what is likely the source of that change.
As markwhitfield annotated here (without any answer to that unfortunately):
https://github.com/ngxs/store/pull/1927/files#r1018904814
this does change behavior:
As soon as subscribing in any way, ngxs disables error logging.
Even if the only subscriber listens for e.g. completion.
The original feature request asked for a solution to stop doubled error logging. #1691
This solution unfortunately makes it 0 error logging for us and likely others :/
Also it is a breaking change which should be documented and not released in a minor version.
I get why the new approach is better for some users...
but many will go blind, not knowing about this change, implementing stuff, not being notified about thrown errors anymore.
I only learned about this because we had some unit tests based on that exact behavior.
Which made me start searching what has changed and then I found out about this PR.
As a compromise, I ask to make this configurable by a root config flag like it was done for
suppressErrors
.By adding a flag
disableErrorPropagationWhenSubscribed
or similar, this can be an opt-in feature,not breaking any behavior for existing implementations.
And it allows any devs plagued by doubled error logging to switch this feature on at any time.
馃敩 Minimal Reproduction
here's a simple reproduction with a jest test.
Environment
Update:
On further debugging, I found it is worse than I thought.
When NOT subscribing, error reporting wont work either.
Not sure what happens, but it seems that inside ngxsErrorHandler,
the code that checks for any subscribers is not executed at all.
Which lets me think of a hot/cold Observable issue first.
I found an additional minor behavior change:
Previously, the error was reported to ErrorHandler in a synchronous way.
Due to the new setup, tests expecting ErrorHandler to be notified immediately, seem to fail too.
So even with a fix that disables discarding of errors in case there are any subscribers,
the test described in reproduction will fail, cause it expects synchronous error reporting.
This will work however:
The text was updated successfully, but these errors were encountered: