#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