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

Dev server doesn't receive SSE close event #12157

Closed
7 tasks done
abcd-ca opened this issue Feb 22, 2023 · 3 comments
Closed
7 tasks done

Dev server doesn't receive SSE close event #12157

abcd-ca opened this issue Feb 22, 2023 · 3 comments
Labels
bug: upstream Bug in a dependency of Vite p2-edge-case Bug, but has workaround or limited in scope (priority)

Comments

@abcd-ca
Copy link

abcd-ca commented Feb 22, 2023

Describe the bug

I am using server-sent events (SSE) and encountered an issue when running Vite dev server.

When a React client is connected to an express.js HTTP SSE endpoint via proxy config, the client should issue a close event that the server receives via res.on('close'...) but the event never fires. When I use vite to create a production build, the server event does get fired.

I have tried doing a low level implementation SSE implementation and also used a higher level library, better-sse. It was reproducible in both cases.

Reproduction

https://github.com/abcd-ca/vite-sse-issue-example

Steps to reproduce

Steps to Reproduce

Dev mode

Demonstrates SSE not closing connections when the browser window is closed or refreshed. You will see in the Chrome DevTools console that client connections are accumulating when you refresh the page which shouldn't happen.

  1. start the app using npm run dev
  2. visit, http://localhost:3000
  3. open the browser console
  4. refresh the page a few times and see the number of connections grow ("There are 1 person(s) here right now!" then "There are 2 person(s) here right now!"...)

Prod mode

Demonstrates SSE disconnect working as expected

  1. build the app using npm run build
  2. start the app using npm start
  3. visit, http://localhost:3001 (make sure you change https to http if your browser changes it automatically)
  4. open the browser console
  5. refresh the page a few times and see the number of connections remain at 1 ("There are 1 person(s) here right now!")

System Info

System:
    OS: macOS 12.6.1
    CPU: (8) arm64 Apple M1
    Memory: 97.45 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.19.0 - /usr/local/bin/node
    Yarn: 1.22.19 - ~/.yarn/bin/yarn
    npm: 8.19.3 - /usr/local/bin/npm
  Browsers:
    Chrome: 110.0.5481.100
    Firefox: 100.0.1
    Safari: 16.1
  npmPackages:
    @vitejs/plugin-react: ^1.0.2 => 1.0.2
    vite: ^2.5.10 => 2.5.10

Used Package Manager

npm

Logs

No response

Validations

@sapphi-red
Copy link
Member

It seems timeout: 0 needs to be set for now: http-party/node-http-proxy#921 (comment)

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  server: {
    proxy: {
      '/api': {
        target: `http://localhost:${PORT}`,
        changeOrigin: true,
        timeout: 0, // here
      },
    },
  },
  build: {
    outDir: 'dist/app',
  },
});

Closing as this is likely a bug in upstream (http-proxy).

@sapphi-red sapphi-red closed this as not planned Won't fix, can't repro, duplicate, stale Feb 24, 2023
@sapphi-red sapphi-red added bug: upstream Bug in a dependency of Vite p2-edge-case Bug, but has workaround or limited in scope (priority) labels Feb 24, 2023
@abcd-ca
Copy link
Author

abcd-ca commented Feb 24, 2023

@sapphi-red thank you for your response and for looking – FYI timeout: 0 does not fix it. Interestingly, some people report to be able to fix a related issue in that ticket you referenced, by disabling gzip compression in webpack, but of course this is Vite not Webpack. It looks like compression is an add-on to Vite that is not in the dev server by default, is that correct? I think it would be wrong to pursue disabling compression in Vite if I did not use such an add-on, right? Another suggestion in that thread is to use a Cache-Control: no transform header but this header is already there for me.

@sapphi-red
Copy link
Member

Oh, it seems I overlooked the address bar. timeout: 0 actually didn't fix. I tried and somehow though it worked.

Yes, Vite does not use compression middlewares in dev.

@github-actions github-actions bot locked and limited conversation to collaborators Mar 12, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug: upstream Bug in a dependency of Vite p2-edge-case Bug, but has workaround or limited in scope (priority)
Projects
None yet
Development

No branches or pull requests

2 participants