#15701 closed defect (wontfix)
[patch] [cla] DeferredList always Resolves even when a child Deferred Rejects
Reported by: | kbenjamin | Owned by: | Mark Wubben |
---|---|---|---|
Priority: | high | Milestone: | tbd |
Component: | Core | Version: | 1.8.0b1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description (last modified by )
As the title says, DeferredList never rejects.
As a result, errors are masked completely unless you set the flag fireOnOneErrback.
The default functionality should match Deferred in that a single error causes the entire DeferredList? to error unless the ConsumeErrors flag is set to true.
This problem appears to exist at least since 1.7.0 through 1.8b1. I haven't checked for earlier cases.
One word of caution about applying the patch: it is possible that the current code is masking existing errors in user, and possibly dijit/dojox code. Fixing this may reveal other errors.
Note that the attached test case is set up to run in a parent directory to dojo, it does not use DOH but simply logs to the browser debug console.
Attachments (2)
Change History (10)
Changed 7 years ago by
Attachment: | DeferredList.patch added |
---|
Changed 7 years ago by
Attachment: | test_DeferredList.html added |
---|
Test case - runs from parent directory of dojo and logs to browser debug console.
comment:1 Changed 7 years ago by
Ken, I would supply a patch to the dojo/tests/DeferredList.js
with a test scenario to cover your change.
comment:2 Changed 7 years ago by
Priority: | undecided → high |
---|---|
Summary: | [patch] [cla] DeferredList always Resolves even when a child Deferred Rejects → [patch] [cla] [regression] DeferredList always Resolves even when a child Deferred Rejects |
comment:3 Changed 7 years ago by
Is this really a regression? Which release did it work correctly in?
comment:4 Changed 7 years ago by
Description: | modified (diff) |
---|---|
Owner: | set to Mark Wubben |
Status: | new → assigned |
Not sure what we want to do with this one. AFAICT this isn't a regression, and DeferredList is deprecated, so it doesn't seem like a big deal. OTOH it's a simple fix.
comment:5 Changed 7 years ago by
I agree with Bill - this is not a regression, I just glanced back to at least 1.6 and this never changed. OTOH, applying the proposed patch would probably *cause* regressions in people's code using DeferredList
.
This sprang out of a thread on the contributors mailing list, where the original problem seemed to be about a sudden silence regarding errors, not suddenly seeing resolution in previously-rejected scenarios. http://mail.dojotoolkit.org/pipermail/dojo-contributors/2012-July/027713.html might be the actual problem.
comment:6 Changed 7 years ago by
Summary: | [patch] [cla] [regression] DeferredList always Resolves even when a child Deferred Rejects → [patch] [cla] DeferredList always Resolves even when a child Deferred Rejects |
---|
comment:7 follow-up: 8 Changed 7 years ago by
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
#15713 may be the real cause of your problems. Kgf and Kitson and I think this ticket (about DeferredList) should be "wontfix" because (1) DeferredList is deprecated in favor of promise/all and (2) like you said, changing this may cause regressions.
comment:8 Changed 7 years ago by
Replying to bill:
#15713 may be the real cause of your problems. Kgf and Kitson and I think this ticket (about DeferredList) should be "wontfix" because (1) DeferredList is deprecated in favor of promise/all and (2) like you said, changing this may cause regressions.
It is not related to #15713 but rather the way DeferredList? is coded to handle errors.
I concur with the conclusions regarding deprecation and possible regressions.
diff from trunk