Skip to content
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: support Readable as the request body #522

Conversation

mikicho
Copy link
Contributor

@mikicho mikicho commented Mar 18, 2024

No description provided.

@kettanaito kettanaito changed the title fix readable fix: support Readable as the request body Mar 19, 2024
@@ -34,7 +34,7 @@ export class MockSocket extends net.Socket {
public write(...args: Array<unknown>): boolean {
const [chunk, encoding, callback] = normalizeWriteArgs(args as WriteArgs)
this.options.write(chunk, encoding, callback)
return false
return true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this affect the fix?

I'm hesitant to return true because it means that the chunk has been sent. However, this method will be called for request bodies that we forward to the interceptor first. Semantically, we are buffering the request chunks so returning false looks more appropriate.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can emit drain instead in onRequestBody/End but this would be unnatural as well.
The more "right" thing to do is to return true/false according to the this.requestStream.push(chunk) in the onRequestBody

Copy link
Member

@kettanaito kettanaito Mar 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My concern is that this is public facing .write() while this.requestStream is an internal stream we use to feed to the HTTP parser. Returning true will notify the consumer (the user/test) that the chunk has been written while it hasn't been. It really gets buffered in the most direct sense of the word. I don't think returning true is correct here.

This can be resolved rather easily:

  • Is this change necessary for the Readable support to work?

If not, let's revert it and discuss it as a separate thing.

Copy link
Contributor Author

@mikicho mikicho Mar 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to either return true or emit a drain event. I have an implementation with the drain event in my local machine.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. Okay, so let's return true since it's the path of least resistance. If it ever causes issues, we iterate. Thanks for pointing this out.

@@ -93,6 +94,31 @@ it('writes Buffer request body', async () => {
expect(await text()).toEqual(expectedBody)
})

it('writes Readable request body', async () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
it('writes Readable request body', async () => {
it('supports Readable as the request body', async () => {

@@ -6,7 +6,8 @@ import http from 'node:http'
import express from 'express'
import { HttpServer } from '@open-draft/test-server/http'
import { ClientRequestInterceptor } from '../../../../src/interceptors/ClientRequest'
import { waitForClientRequest } from '../../../helpers'
import { sleep, waitForClientRequest } from '../../../helpers'
import { Readable } from 'node:stream'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: could you please move this import to the top of the file? Thanks!

Michael Solomon added 2 commits March 20, 2024 20:32
@kettanaito
Copy link
Member

I've opened #527 as a feature branch from the socket interceptor branch (yours points to the same branch so it's a bit problematic to iterate on).

@kettanaito kettanaito closed this Mar 21, 2024
@mikicho mikicho deleted the feat/yet-another-socket-interceptor branch March 21, 2024 18:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants