cloudflare / workers-sdk

⛅️ Home to Wrangler, the CLI for Cloudflare Workers®
https://developers.cloudflare.com/workers/
Apache License 2.0
2.75k stars 734 forks source link

🐛 BUG: `wrangler dev` doesn't stream compressed response while deployed workers do #6577

Open hi-ogawa opened 3 months ago

hi-ogawa commented 3 months ago

Which Cloudflare product(s) does this pertain to?

Wrangler

What version(s) of the tool(s) are you using?

3.72.2 (the issue happens since 3.49.0)

What version of Node are you using?

20.17.0

What operating system and version are you using?

Linux 6.10 Arch Linux

Describe the Bug

Observed behavior

It looks like wrangler dev is not streaming compressed response, for example, for browser's text/html request. The example code is included below in the reproduction and following screenshots show the difference between wrangler dev and deployed workers:

Screenshots `wrangler dev` http://localhost:8787 [Screencast from 2024-08-24 19-16-18.webm](https://github.com/user-attachments/assets/4db9367d-f4c2-4e76-8ddf-ccc444b13ca3) deployed version https://repro-wrangler-stream-response.hiro18181.workers.dev [Screencast from 2024-08-24 19-18-00.webm](https://github.com/user-attachments/assets/9ebd006d-8181-48dd-8954-74c3e5e0ff4e)

Expected behavior

wrangler dev should work similar to deployed version.

Steps to reproduce

reproduction is provided below

Please provide a link to a minimal reproduction

https://github.com/hi-ogawa/reproductions/tree/main/wrangler-stream-response

Please provide any relevant error logs

No error logs

Additional context

I initially discovered this issue in https://github.com/hi-ogawa/vite-plugins/pull/523 when upgrading wrangler >= 3.49.0. I have e2e tests for React streaming SSR (content-type text/html) and also RSC requests (content-type text/x-component). While deployed version works in both cases (for example https://rsc-experiment.hiro18181.workers.dev/test/loading/1), but equivalent tests for wrangler dev are failing since wrangler 3.49.0.

I'm not entirely sure whether streaming response is reliable when there is a compression and maybe some variance is expected. I would appreciate if there's any clarification on this if this is an expected behavior.

For example, the deployed version in the reproduction wasn't actually streaming properly until I put "dummy comment" to the streaming payload https://github.com/hi-ogawa/reproductions/blob/b718cf55c782e200d61b319132be1469d26800f0/wrangler-stream-response/index.js#L19-L20 Perhaps, compressed streaming depends on the size of the payload in practice?

Another thing, probably not relevant to wrangler but just in case, vite preview has non-streaming compression, so I often strip off accept-encoding from middleware to allows testing streaming SSR https://github.com/hi-ogawa/vite-plugins/blob/b446fcc6833a55987ef1ac0a9fc6479ea8246e52/packages/react-server/examples/basic/vite.config.ts#L57-L67 If there's any workaround like this to test streaming response of wrangler dev, then that would be great too (though probably it's not ideal to turn off compression since that would be bigger inconsistency with deployed workers).

MaxBittker commented 2 months ago

still affected by this, are there any workarounds besides downgrading?

sleexyz commented 2 months ago

bumping this, this breaks any kind of streaming response i.e. LLM response output.

hi-ogawa commented 2 months ago

As a workaround, it looks like you can force no compression by adding content-encoding: identify, which should enable streaming. I just learned this from Hono https://github.com/honojs/hono/issues/3449

In my reproduction, it would look like this:

    return new Response(stream, {
        headers: {
            "content-type": "text/html",
            "content-encoding": "identity",
        },
    });