-
Notifications
You must be signed in to change notification settings - Fork 3k
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
fromFetch cannot abort all responses #4744
Comments
This is resolved in 6.5.2 |
Nope. This isn't resolved. With the current implementation, it's not possible to abort responses that use the chunked transfer encoding or another mechanism that results in only a partial body being available at the time |
@cartant should the canceling of a chunked response via
|
@curiousercreative Nope. The PR with the selector - a selector has to be passed in the |
@cartant hey, that's great news! I'll be looking forward to the next release. Thanks for adding this feature. |
@curiousercreative BTW, if you are interested, the reason for the selector is explained here: https://ncjamieson.com/understanding-fromfetch/ |
@cartant thanks for that follow-up. My implementation actually doesn't have to wait for the next release. In my case, I'm streaming my chunked response using |
Bug ReportFeature RequestCurrent Behavior
fromFetch
returns an observable that emits the request'sResponse
object. Whenjson()
ortext()
is called on theResponse
, a promise is returned. My understanding is that theAbortController
used in thefetch
call also aborts promises returned by the aforementioned methods.In #4742, a bug was fixed:
fromFetch
was callingabort
as part of the implicit unsubscribe that occurs after completion. This would abort any still pending responses. Whenfetch
resolves, a flag is now set to preventabort
being called in the unsubscribe teardown.However, that means there is no way of aborting the promises returned by calls to
Response
methods.Possible Solution
Add another signature to
fromFetch
so that a selector can be passed:Much like the selector passed to
multicast
, observables composed within the selector will be 'contained' within the observable returned byfromFetch
and unsubscribing from said observable will facilitate the aborting of any promises returned byResponse
methods within the selector.If a selector is not passed,
fromFetch
should continue to behave as in #4742 and not abort upon unsubscription if the promise returned byfetch
has resolved.Additional Information
Note that the changes introduced in https://github.com/ReactiveX/rxjs/pull/3963/files will ensure that unsubscription from the observable returned by
fromFetch
will occur ASAP if said observable serves as the source for, say,concatMap
. So extending the 'life' of theAbortController
for an emittedResponse
- if the selector is not used - would be a non-trivial undertaking.The text was updated successfully, but these errors were encountered: