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

onResponse hook TypeScript definition issue with response.stream. #383

Open
2 tasks done
gwicks opened this issue Sep 23, 2024 · 2 comments
Open
2 tasks done

onResponse hook TypeScript definition issue with response.stream. #383

gwicks opened this issue Sep 23, 2024 · 2 comments

Comments

@gwicks
Copy link

gwicks commented Sep 23, 2024

Prerequisites

  • I have written a descriptive issue title
  • I have searched existing issues to ensure the bug has not already been reported

Fastify version

5.0.0

Plugin version

11.0.1

Node.js version

20.x

Operating system

macOS

Operating system version (i.e. 20.04, 11.3, 10)

14.5

Description

(I did check this issue as well, but doesn't seem immediately related: #334 )

Hello,

I am using the onResponse hook to properly implement some custom tracing with OpenTelemetry and need the hook to otherwise behave normally, but trigger some extra logic to clean up a OpenTelemetry Span stored in the request. Note that I am using this inside of @fastify/http-proxy but the underlying issue is coming from this package since that package simply wraps this one.

There seems to be a moderate issue when using TypeScript and overriding the onResponse hook. Specifically, there's seemingly no good way to access the stream on RawReplyDefaultExpression<RawServerBase> that's assigned to the res in that hook. I see that it's defined in Http2ServerResponse type in Fastify, and that RawReplyDefaultExpression is supposed to be a union of all the possible response types (HTTP and HTTP2). I have my proxy configured as HTTP/1.

Previously, I was able to get away with

onResponse: async (
        request,
        reply,
        res: RawReplyDefaultExpression<RawServerBase>
      ) => {
        if (request.currentSubspan) {
          request.currentSubspan.setAttribute(
            "reply.elapsedTime",
            reply.elapsedTime
          );
          request.currentSubspan.end();
          request.currentSubspan = null;
        }
        reply.send(res);
    }
),
http2: false,

But upon upgrading to Fastify 5.x and the latest version of this plugin, this no longer functions, despite res itself being defined as a stream. Using this approach currently results in a blank response where it previously.

If you try to use res.stream, you will get the following error in the TypeScript compiler.

Property 'stream' does not exist on type 'RawReplyDefaultExpression<RawServerBase>'.
  Property 'stream' does not exist on type 'ServerResponse<IncomingMessage>'.

Right now, my workaround is.

      onResponse: async (
        request,
        reply,
        res: RawReplyDefaultExpression<RawServerBase>
      ) => {
        if (request.currentSubspan) {
          request.currentSubspan.setAttribute(
            "reply.elapsedTime",
            reply.elapsedTime
          );
          request.currentSubspan.end();
          request.currentSubspan = null;
        }
        // eslint-disable-next-line @typescript-eslint/no-explicit-any
        reply.send((res as any)?.stream);
      },
      http2: false,

This is really suboptimal for pretty obvious reasons. The actual structure of response is not reflected in the TypeScript definition, so as a result, it's difficult to use properly. I suppose the "fix" here would be to ensure there's a definition of stream in the type definition.

Link to code that reproduces the bug

No response

Expected Behavior

I would expect the response.stream property to be defined in some fashion in the exported TypeScript definitions for the onResponse hook.

@mcollina
Copy link
Member

Thanks for reporting! Would you like to send a Pull Request to address this issue? Remember to add unit tests. We use tsd for types

@gwicks
Copy link
Author

gwicks commented Oct 14, 2024

Unfortunately not familiar with tsd myself but I can try to put together a PR to address the issue. Main thing is handling the different "backends" this package can use (Undici, Node HTTP, and Node HTTP/2), which all have different stream response types. Granted, we could just go with unknown or a union of all the possible types. Not sure what the best path forward is, honestly.

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

No branches or pull requests

2 participants