-
Notifications
You must be signed in to change notification settings - Fork 2k
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(race): concurrent next calls with defer/stream #2975
fix(race): concurrent next calls with defer/stream #2975
Conversation
f70ec66
to
c3f9508
Compare
c3f9508
to
9680b06
Compare
3fd57a8
to
e272823
Compare
@robrichard @IvanGoncharov ready for review |
Although this change suggests that _subsequentPayloads should be a set rather than an array |
This PR fixes by modifying the general approach as little as possible, we still create Promise reactions to all the pending promises on each call to See #2848 (comment) where I link to https://github.com/repeaterjs/repeater/blob/219a0c8faf2c2768d234ecfe8dd21d455a4a98fe/packages/repeater/src/repeater.ts#L687 that uses a different approach to convert all pending promises to async iterables (which each yield one value) and then combining those iterables in settle order. If you would be more open to that type of approach, I can try to see if I can work to extract it (maybe with the help of @brainkim) |
@yaacovCR thanks again for your help on this. I'm not tied to the current approach. I think a generic well-tested jsutil that can combine and race promises and async iterables makes sense. |
@robrichard @IvanGoncharov I think the best path forward so as to not lose steam/forward momentum with any experimenters, would be to merge this bug fix that keeps the existing approach, and then as a separate PR, see if myself or @brainkim is able to work something else out in a refactor. |
tests failing, on the bright side, it means that our test coverage is meaningful :) at least some tests are failing because of a bug in current defer/stream implementation, see graphql/graphql-js#2975
Would this be accepted if rebased? graphql tools stitching support uses patch package to apply this fix.... |
@yaacovCR I'm planning to spend some time refactoring the dispatcher to a generic jsutil that can be more easily tested and handle all the edge cases |
Sure but until then can we merge it so the bug is fixed |
ace3509
to
1eaed52
Compare
Meaning prior to next experimental release it would be nice if fixed somehow with this PR if not a refactor |
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
This seems to work with me for my project.
not quite sure what to do about isDone which seems to be used just when return is called (parenthetically, should that be renamed to isReturned for clarity/distinction between
isDone
anddone
attributes?)namely, should the isDone check go up top prior to checking for the next resolved promise, within the next resolved promise check, or maybe both.
in general, not sure how we are really handling secure stopping issues, seems like -- for example -- there could be condition in which we await a promise which never resolves, but that is ok, because return has been called?
but still quite the novice with all of this async stuff
---From my opinionated perspective, I realize that graphql-js is a reference lib, and has a zero-dependency footprint, but seems like handling all these async issues (in JS in general and within
graphql-js
) would be easier with a Repeater-like construct (see https://repeater.js.org/, @brainkim) that could be even theoretically inlined in downsized version intojs-utils
.