Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Support aborting requests in handlers #1962

Closed
2 tasks
kettanaito opened this issue Jan 12, 2024 · 1 comment
Closed
2 tasks

Support aborting requests in handlers #1962

kettanaito opened this issue Jan 12, 2024 · 1 comment
Labels

Comments

@kettanaito
Copy link
Member

kettanaito commented Jan 12, 2024

Scope

Adds a new behavior

Compatibility

  • This is a breaking change

Feature description

I think it would be useful to give the user the API to abort any intercepted request in a matching request handler.

Note that this doesn't conflict nor replace the user-defined AbortController on the request. The user-defined controller is there for the user to abort the request as a part of their app. The proposed feature is for the user to abort the request as a part of the hander.

http.get('/resource', async ({ request, controller }) => {
  await delay(500)
  controller.abort(reason)
})

How would this work?

The controller API would hook into the existing request.signal, or create one, if it's not defined. Internally, we will have the controller.signal.on('abort') listener to know if the user aborted the request in the handler. If they did, we will translate that event to the appropriate mechanism to abort the request:

Browser

  • Forward the abort event to the existing/added request.signal abort controller to abort the request for free.

Node.js

  • Listen to the controller.signal.on('abort') and abort the request via appropriate means:
    • ClientRequest: by calling this.abort() on the ClientRequest instance. I'm not proposing to attach the signal on the request instance to have as little meddling with the user-defined signal as possible. The downside of tapping into this.abort() directly may be that the user-defined signal will never receive that abort event (because there's no event, we are aborting the request on the lower level).
    • XMLHttpRequest: by calling this.abort() on the XMLHttpRequest instance.
    • fetch: by forwarding the abort event to the existing/added abort controller on the request instance.

Questions

  • What is the semantics of aborting the request in a handler? Handlers stand for server-side behavior. Would this translate to the "server is aborting this request"?
@kettanaito
Copy link
Member Author

Relevant issue opened in the Interceptors: mswjs/interceptors#520.

@mswjs mswjs locked and limited conversation to collaborators Mar 21, 2024
@kettanaito kettanaito converted this issue into discussion #2104 Mar 21, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
Projects
None yet
Development

No branches or pull requests

1 participant