All Issues
24,993 verified issues
Socket.IO HTTP polling causes 400 errors on multi-instance AWS load balancer
Socket.IO connections work on single-instance deployments but fail with HTTP 400 errors when the app is scaled to multiple instances behind an AWS ALB without sticky sessions. Socket.IO's default transport starts with HTTP long-polling before upgrading to WebSocket. Polling requests may hit a different server instance that has no knowledge of the session established by the first request.
localStorage not cleared on logout causes cross-account data leak
User A logs in and generates data stored in localStorage (e.g. draft schedules, cached filters, pending items). When User A logs out and User B logs in on the same browser, User B sees User A's localStorage data because logout does not clear app-specific localStorage keys. This is a security issue when apps rely on localStorage for sensitive state.
The library is not compatible with webpack
The library is not compatible with webpack
Twilio Verify VerificationCheck is out of date.
The underlying API for verify has changed but the documentation / library has yet to be updated to reflect these changes. This is very misleading due to the documentation directly stating that `V2` should be used instead of `V1`. Reference: `V1 of the API will be maintained for the time being, but any new features and development will be on Version 2. We encourage you to do any new development with API V2.` Version: `3.32.0` Code Snippet [code block] Exception/Log [code block] Steps to Reproduce 1. Make request defined in `Code Snippet` 2. Get error defined in `Exception Log` Feature Request N/A
"Session ID unknown" after handshake on high server load [Socket.io 1.0.6]
I am running a multi-node server (16 workers running Socket.io 1.0.6; accessed via Nginx, configured as a reverse proxy supporting sticky sessions) for ~ 5k users. While the load of the server is low (2~3 on a 20 core server / 2k users), everyone is able to connect instantly. When the load of the server gets higher (5~6 / 5k users), new users are not able to connect and receive data instantly. In this case, it takes 2~4 handshakes for the users to connect succesfully. This is what happens (high load): - User opens the website; receives HTML and JS - User's browser attempts to initialize a socket.io connection to the server (`io.connect(...)`) - A handshake request is sent to the server, the server responds with a SID and other information (`{"sid":"f-re6ABU3Si4pmyWADCx","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":60000}`) - The client initiates a polling-request, including this SID: `GET .../socket.io/?EIO=2&transport=polling&t=1408648886249-1&sid=f-re6ABU3Si4pmyWADCx` - Instead of sending data, the server responds with 400 Bad Request: `{"code":1,"message":"Session ID unknown"}` - The client performs a new handshake (`GET .../socket.io/?EIO=2&transport=polling&t=1408648888050-3`, notice the previously received SID is omitted) - The server responds with new connection data, including a new SID: (`{"sid":"DdRxn2gv6vrtZOBiAEAS","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":60000}`) - The client performs a new polling request, including the new SID
Cannot Resolve 'uws', Update README or "package.json"?
Note: for support questions, please use one of these channels: stackoverflow or slack You want to: [x] report a bug [ ] request a feature Current behaviour I downloaded the example project webpack-build-server from socket.io's master branch, run `npm install` to install the dependencies, and finally run `npm run build` to try to bundle the server, but webpack gives me the following errors: [code block]` Steps to reproduce (if the current behaviour is a bug) 1. Download socket.io's master branch 2. Go to `examples/webpack-build-server`; 3. Run `npm install`; 4. Run `npm run build`; Note: the best way to get a quick answer is to provide a failing test case, by forking the following fiddle for example. Expected behaviour A server.js file should be produced in `dist` folder. Setup - OS: macOS Hight SIerra - browser: Safari - socket.io version: 2.0.3 Other information (e.g. stacktraces, related issues, suggestions how to fix) These are what's printed in my terminal [code block]` Update I install `uws` package manually and it seems to work. Can someone update the README file or package.json since it's really hard for a beginner like me to figure this out.
Dev server must be restarted to have classes applied with Snowpack
What version of @tailwindcss/jit are you using? 0.1.4 What version of Node.js are you using? 14.2.0 What browser are you using? Chrome What operating system are you using? macOS Reproduction repository https://www.youtube.com/watch?v=G6d-SXdcJXs Hi there ☺️ I tried to use this new JIT feature with a new React app built with Snowpack. Unfortunately, I cannot have Snowpack use Tailwind JIT properly. I think I might have missed something about the configuration process. When changing a class in a component, I have to stop and restart the dev server. Here are my config files: [code block] [code block] [code block] Thanks!
Roadmap for v3
This list is open to suggestions! - [ ] Improve the documentation That is obviously the major pain point of the project. - [x] Reverse the direction of the ping-pong mechanism Currently the client emits a `ping` and waits for a `pong` from the server, relying on `setTimeout()` to check whether the connection is still alive or not. But there are reports of throttled timers on the browser side, which may trigger random disconnections. A solution would be that the `ping` is emitted from the server to the client, but that is a breaking change which will also break other client implementations.. Related: https://github.com/socketio/socket.io/issues/5082 - [x] Update the source code to ES6 in every project - [x] Migrate to webpack 4 (or another bundler, if need be) - [ ] Remove the sticky-session requirement when using multiple nodes - [ ] Default to websocket, and use XHR polling as fallback Currently polling is established first, and then upgraded to websocket if possible. - [x] Make the `generateId` method asynchronous This one is also a breaking change. Related: https://github.com/socketio/engine.io/pull/535 - [ ] Update the Typescript bindings, if need be - [ ] Triage issues No release date for now, as I'm not sure how much time I will be able to dedicate to those points in the following weeks. But any help is welcome!
Axios post request network error on android
Describe the bug 0 So i'm posting a formdata object with axios to a node.js server. On iOS everything works perfectly, the data get posted and the image uploaded. But on android i'm getting this error. PLEASE NOTE THAT I DID READ THE PREVIOUS ISSUES AND TRIED THE SOLUTION. NOTHING WORKED ! To Reproduce Code snippet to reproduce, ideally that will work by pasting into something like https://npm.runkit.com/axios, a hosted solution, or a repository that illustrates the issue. If your problem is not reproducible, please file under Support or Usage Question [code block] Please note that on iOS it works without a problem. here's a screenshot of the error when i used the react native debugger Expected behavior FORMDATA OBJECT POSTED TO NODE.JS server Environment - Axios Version 0.27.2 - Adapter : HTTP - Browser : Chrome - Browser : Version 103.0.5060.53 (Official Build) (arm64) - Node.js : v14.17.5 - OS: macOS big sur version 11.4 - expo: "~45.0.0" - "react-native": "0.68.2", Additional context/Screenshots Add any other context about the problem here. If applicable, add screenshots to help explain.
Date column returns a date string instead of a date object
Issue type: [ ] question [x] bug report [ ] feature request [ ] documentation issue Database system/driver: [ ] `cordova` [ ] `mongodb` [ ] `mssql` [ ] `mysql` / `mariadb` [ ] `oracle` [x] `postgres` [ ] `sqlite` [ ] `sqljs` [ ] `react-native` TypeORM version: [ ] `latest` [ ] `@next` [x] `0.2.6` (or put your version here) If I set a date column with `@CreateDateColumn({type:'Date'})` in an entity. The result contains a date string `{created: "2018-05-18"}` instead of a date object. I think it's a bug because a date time column `@CreateDateColumn()` would return a date object. [code block]`
next.js ENOENT trying to open schema.prisma
Bug description In a monorepo, when exporting `PrismaClient` from one package and consuming it in a next.js api route, I get [code block] How to reproduce 1. Git clone https://github.com/SimonBerens/prisma-pnpm-workspace-test 2. run [code block] 3. send a GET request to `localhost:3000/api/hello` Expected behavior The api runs as expected Prisma information [code block] Environment & setup - OS: Windows 11 - Database: PostgreSQL - Node.js version: v16.14.2 Prisma Version [code block]
Within a dev container using Docker 26, `vite dev` or `vite preview` cannot be accessed from the host
Describe the bug I initialy though this was a case of https://github.com/vitejs/vite/issues/11468#issuecomment-2073871487, but it seems it is something else, so I am opening another issue. Using Dev Containers for development, and after upgrading to Docker 26 (from 25) on the host, I am unable to connect to either `vite dev` or `vite preview` server using the default and basic port forwarding feature of the dev containers. By "unable to connect", I mean that the server is launched, however when trying to connect from my host using `http://localhost:4200/`, either Chromium or Firefox Dev Edition request hangs indefinitely on loading (it stays in loading state without timing out for at least for a good 5-10 minutes; didn't test longer than that). I am using Nx, but using vite directly does not change the outcome. For the recoard, I also have a `dotnet` server that is responding as expected to the request, so for now (in my limited available code base), this point out to `vite`, but it may well be due to whichever node server backend vite is using. Reproduction unable to provide without control of the host docker version Steps to reproduce _No response_ System Info Dev Container I am using a custom pre-built image, which is a copy of `mcr.microsoft.com/devcontainers/typescript-node:20` [code block] Host - `docker-ce-cli (5:26.1.0-1~ubuntu.22.04~jammy)` - `docker-ce (5:26.1.0-1~ubuntu.22.04~jammy)` [code block] Used Package Manager pnpm Logs <details> <summary>
Support setting a timeout for SQLite
Problem SQLite queries fail immediately if the DB is locked. I blindly tried passing arguments similarly to how the docs show for PostgreSQL, needless to say, it didn't work. [code block]
[BUG] npx package@version uses incorrect installed version in npx 7
Current Behavior: running `npx @package@version` generate it with the current install version Expected Behavior: it should be generated with the given version Steps To Reproduce: ex. steps to reproduce the behavior: 1. run `npm i -g npm@latest` to install npm 7 2. run `npx @angular/cli@next new` 3. answer all questions of the angular cli, it doesn't matter what the answers are 4. it will install angular 11 (while next is 12) Environment: - OS: Windows 10 - Node: 14.16.1 - npm: 7.12.0 (working fine with 6.14.13)
Next.js 14 rejects next.config.ts — only .mjs or .js supported
Creating next.config.ts causes the dev server and build to fail silently or with cryptic errors. Next.js 14 does not support TypeScript config files — only next.config.js or next.config.mjs. The error is not obvious because the file appears to be read but config options are silently ignored.
Lambda cold starts increase to 8–12 seconds after migrating to Node.js 20
After migrating AWS Lambda functions from Node.js 18 to Node.js 20, INIT_DURATION in CloudWatch logs jumps from ~400ms to 8–12 seconds. Warm invocations are normal speed. The regression is caused by Node.js 20 changes to module loading combined with webpack-bundled code that initializes all modules eagerly, including heavy AWS SDK v2 imports that are not tree-shakeable.
OpenAI SDK instantiated at module level crashes Next.js build
Calling `new OpenAI()` or `new OpenAI({ apiKey: process.env.OPENAI_API_KEY })` at the top level of a module (outside a function) causes next build to crash. During static analysis, Next.js evaluates module-level code and process.env.OPENAI_API_KEY is undefined, which throws an OpenAI client error before any route runs.
Intermittent "Connection is closed" errors
We are currently working on a Lambda function, which connects to a Redis 3.2.10 cluster on [AWS Elasticache][aws-ec]. This Lambda function will connect to the Redis cluster, run `KEYS` on each master node, collect the responses from each node and return an array of keys. We then publish an SNS message for each key in this array, then close the cluster connection, before the Lambda ends. AWS Lambda freezes and thaws the container in which programs run. So, ideally we would create a connection once then re-use it on every invocation. However, we have found that for the Lambda to end, we must explicitly end the client connection to the cluster as Lambda waits for the Node event loop to empty before the Lambda ends. This is why we create the connection at the start of the function (representing a Lambda invocation) run our queries and then when this completes we attempt to gracefully `.quit()` the `Redis.Cluster` connection. I can't share the actual code that we're working on, but I've been able to extract the logic and create a simple example of the issue we're facing: `test.js` [code block] Example output: [code block] Why would we be getting the `Connection is closed` rejection error? This feels like a bug, as I think we are going about this in the correct way, but I'm happy to be proved wrong! [aws-ec]: https://aws.amazon.com/elasticache/
Way to handle mongoose.connect() error in promise catch handler
How to handle `mongoose.connect()` error in catch handler? I want to use application initialization chain but can't do that because `mongoose.connect()` does not return rejected promise. It returns rejected promise only if I specify callback, but it's not a perfect solution. Example: [code block] Workaround: [code block] I think `mongoose.connect()` throws async error instead of return rejected promise in order to not break backward compatibility. Users expect that application will be finished with error code if something went wrong with mongoose connection establishment. If `mongoose.connect()` returns rejected promise application will be finished with 0 code and nothing will be output to console. So it will be good to have some way to say `mongoose.connect()` to return promise. Maybe something like `exec()`: [code block]
Why are null and undefined variables removed from params
https://github.com/axios/axios/blob/638804aa2c16e1dfaa5e96e68368c0981048c4c4/lib/helpers/buildURL.js#L38 I would expect [code block] To construct `?a=&b=`