All Issues
24,993 verified issues
[BUG]: TypeError: movedTables is not iterable
What version of `drizzle-orm` are you using? "^0.32.0" What version of `drizzle-kit` are you using? "^0.23.0" Describe the Bug I ran introspect command and following were the error bunx drizzle-kit introspect drizzle-kit: v0.23.0 drizzle-orm: v0.32.0 No config path provided, using default path Reading config file '/Users/some_dirs/drizzle.config.ts' Pulling from ['product'] list of schemas Using 'pg' driver for database querying [✓] 192 tables fetched [✓] 1074 columns fetched [✓] 0 enums fetched [✓] 0 indexes fetched [✓] 285 foreign keys fetched TypeError: movedTables is not iterable at applyPgSnapshotsDiff (/Users/some_dirs/node_modules/drizzle-kit/bin.cjs:29346:22) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async introspectPostgres (/Users/some_dirs/node_modules/drizzle-kit/bin.cjs:126156:42) at async _Command.<anonymous> (/Users/some_dirs/node_modules/drizzle-kit/bin.cjs:131714:7) And the following warnings/errors were shown in the vscode Cannot find name 'nextval'. Cannot find name 'regclass'. export const resource = our_schema.table("resource", { resource_id: uuid("resource_id"), clicked_at: date("clicked_at").defaultNow(), clicker_ip: varchar("clicker_ip"), clicked_by: varchar("clicked_by"), id: integer("id").default(nextval('ourschema.social_clicks_id_seq'::regclass)).notNull(), }); Expected behavior _No response_ Environment & setup _No response_
socket.io crashes Mobile Safari on iOS
I am having an issue with Mobile Safari crashing on iOS. The following will consistently reproduce a crash for me: 1. Load a page in Mobile Safari that connects using socket.io. 2. Click the "change tab" button and navigate to a different tab to put the current tab in the background. 3. Send a message from the server to the client. 4. Navigate back to the original tab (the one that connected via socket.io). Mobile Safari crashes. I think it is related to this: https://gist.github.com/2052006 The page above includes a workaround, but I'm not sure how to implement this workaround with socket.io.
[Cluster] Failed to refresh slots cache
Hey, I am using this docker image to setup my redis cluster. When I connect via a desktop client (Medis), everything is working fine. When I try to connect deepstream.io (which uses`ioredis`) to the cluster, I get the `Failed to refresh slots cache` error. I know there are other issues with the same error, but none of them provided a solution to solve this problem. The fact that I can connect via my desktop tool and not via `ioredis` is pretty weird.
Target specific client on clustered socket.io server and using acknowledgment callback
I've clustered my socket.io server and I'm looking for a way to emit to a specific client and receiving a acknowledgment callback. The problem that the server doesn't have a reference to a instance of the target client, because this client can be connected to another socket.io server instance (because it's clustered). I know I can emit to a room named after the the socket.id or a custom room where I put the client in. But the problem is that this is considered broadcasting and then I can't use a acknowledgment callback. I don't want to add complexity to the target client. The target client should just be able to call the callback. I see two possible solutions: - Find a way to create a fake socket instance with the socket.id (so I can use existing callback code) - Broadcast to a room and build my own callback system, see: https://github.com/Automattic/socket.io/issues/1656#issuecomment-49077695 A fake socket instance wouldn't actually have a connection to a client, but I hope to use it's emit function, have it talk to it's adapter (socket.io-redis) and have it receive the acknowledgment callback. Any tips on these solutions, maybe something I should also consider.
Please support vector sizes of 20,000 like PinconeDb
I would much rather use pgVector with PostgreSQL than Pinecone. Any suggestions? Thanks.
defaut error handler (finalhandler) should not prevent the response being sent
Or else there should be an option to provide a custom made final handler. Why: I use 2 error handlers in my app : one that logs the error in our database, and one that returns a 500 to the client, with an particular error message. If for any reason I have two bits of async code that both rise an error, the app just throws the 2nd error to stderr and don't return anything (not even the first 500) to the client. So the bug is : first error calls next(err) two times and traverses my 2 error handlers. But when next(err2) is called on the 2nd error, we are already beind my 2 error handlers in the route stack, and the finalHandler is called. This happens often in a rest api style app (which is our case) : some route ask to do some operation on multiple business objects, we do all operations in, for instance, a "async.parallel", but due to a legitimate problems, some of those operations return an error. In such case, I would like to configure my app to do : log all the errors to the database send to the client a proper error 500 with a custom message corresponding to the first error that occured (there is a good chance the next errors will have the same cause and message, but even if not, this is still the desired behaviour) I read an argument saying that if we are sending a "normal" response to the client, and an error occur, it's preferable to stop everything, that to finish sending the response to the client and making it belive that everything is OK. I would argue that :
v4.17.0 breaking change for Redis parser
Release v4.17.0 fails to parse username:password combinations for redis version 5 and lower. The Rediss / Redis URL connection strings are no longer valid. [code block]
[ServerErrors][TypeScript] 5.0.0-dev.20230207
The following errors were reported by 5.0.0-dev.20230207 Pipeline that generated this bug Logs for the pipeline run File that generated the pipeline This run considered 200 popular TS repos from GH (after skipping the top 0). <details> <summary>Successfully analyzed 195 of 200 visited repos</summary> | Outcome | Count | |---------|-------| | Detected interesting changes | 122 | | Detected no interesting changes | 73 | | Git clone failed | 1 | | Unknown failure | 4 | </details> Investigation Status | Repo | Errors | Outcome | |------|--------|---------| |adonisjs/core|1| | |akveo/ngx-admin|1| | |alibaba/ice|1| | |angular/angular-cli|1| | |angular/angular|1| | |angular/components|1| | |ant-design/ant-design-pro|1| | |ant-design/ant-design|1| | |apache/echarts|1| | |apollographql/apollo-client|1| | |appsmithorg/appsmith|1| | |appwrite/appwrite|1| | |babel/babel|1| | |backstage/backstage|1| | |baidu/amis|1| | |blitz-js/blitz|1| | |BrainJS/brain.js|1| | |Budibase/budibase|1| | |BuilderIO/qwik|1| | |chakra-ui/chakra-ui|1| | |chartist-js/chartist|1| | |codex-team/editor.js|1| | |compiler-explorer/compiler-explorer|1| | |conwnet/github1s|1| | |CopyTranslator/CopyTranslator|1| | |darkreader/darkreader|1| | |date-fns/date-fns|1| | |desktop/desktop|1| | |directus/directus|1| | |elastic/kibana|1| | |electron-userland/electron-builder|1| | |Eugeny/tabby|1| | |excalidraw/excalidraw|1| | |facebook/docusaurus|1| | |felixrieseberg/windows95|1| | |flatpickr/flatpickr|1| | |floating-ui/flo
GraphQL doing unnecessary/repetitious requests/resolves.
Hi, Given the following type language schema: [code block] and the following query: [code block] we see the following requests for data on the backend: [code block] [uids are generated per unique call to `resolve`]. These repetitious requests came as a surprise given that one of GraphQL's biggest selling points is the elimination of N+1 queries and the introduction of intelligent caching/simplification/reduction etc etc etc Is this a known issue?
[NewErrors] 6.0.0-dev.20250921 vs 5.9.2
The following errors were reported by 6.0.0-dev.20250921, but not by 5.9.2 Pipeline that generated this bug Logs for the pipeline run File that generated the pipeline This run considered 800 popular TS repos from GH (after skipping the top 0). <details> <summary>Successfully analyzed 455 of 800 visited repos</summary> | Outcome | Count | |---------|-------| | Detected interesting changes | 262 | | Detected no interesting changes | 193 | | Git clone failed | 10 | | Package install failed | 103 | | Project-graph error in old TS | 10 | | Too many errors in old TS | 195 | | Unknown failure | 27 | </details> Investigation Status | Repo | Errors | Outcome | |------|--------|---------| |actualbudget/actual|2| | |adobe/react-spectrum|6| | |ag-grid/ag-grid|8| | |ag-ui-protocol/ag-ui|2| | |aidenybai/react-scan|4| | |airbnb/react-sketchapp|1| | |ajv-validator/ajv|1| | |akveo/nebular|13| | |akveo/ngx-admin|3| | |akveo/react-native-ui-kitten|2| | |alan2207/bulletproof-react|2| | |alexta69/metube|1| | |alibaba/formily|7| | |alibaba/hooks|2| | |alibaba/ice|7| | |alibaba/lowcode-engine|2| | |amplication/amplication|30| | |AmruthPillai/Reactive-Resume|9| | |angular-ui/ui-router|4| | |apache/superset|1| | |api-platform/api-platform|1| | |APIs-guru/graphql-voyager|2| | |apitable/apitable|1| | |arc53/DocsGPT|1| | |arwes/arwes|21| | |aurelia/framework|1| | |aws-amplify/amplify-js|9| | |AykutSarac/jsoncrack.com|1| | |balena-io/etcher|1| | |basarat/typescript-book|1| | |beekeeper-studio/beekee
[BUG]: drizzle-orm/planetscale-serverless reuses connection, leading to inconsistent issues
What version of `drizzle-orm` are you using? 0.29..3 What version of `drizzle-kit` are you using? 0.20.9 Describe the Bug When using planetscale with drizzle, the planetscale connection is reused for subsequent queries to the db. This is an incorrect usage of the planetscale/database driver and can lead to issues with queries/returns in parallel transactions/queries. see: https://github.com/planetscale/database-js/issues/139 & https://github.com/mattrobenolt/ps-http-sim/issues/1 The issue was highlighted here: https://github.com/mattrobenolt/ps-http-sim/issues/7#issuecomment-1864636196 In my local testing: when using the planetscale/database driver directly, for each query a new connections+session is created when using via drizzle-orm/planetscale-serverless, a single connection is created and reused for each subsequent query until the connection is closed by the PS server how this was discovered: A planetscale simulator was created by @mattrobenolt who also works at PS. the logs and errors returned by the simulator highlighted this discussion here: https://github.com/mattrobenolt/ps-http-sim/issues/7 how to test/replicate: use the planetscale simulator docker compose example and monitor logs: https://github.com/mattrobenolt/ps-http-sim run multiple drizzle queries in quick succession check docker logs for how many sessionIds were created Run the same queries directly using `@planetscale/database` recheck docker logs and count sessionIds example log [code block] E
After integrating Api getaway and lambda on Amazon console I see error lile "Could not list api-gateway event sources."
Serverless Framework Version: beta 1.0 Operating System: windows Additional Details: After integrating Api getaway and lambda on Amazon console(Lambda tab) I see error lile "Could not list api-gateway event sources." My yaml file: Functions: lambdaFunction: handler: com.myHandler.DataExtractorLambda events: - schedule: cron(0/1 \ \ \ ? ) - http: path: publicGetaway/getResources method: get Note: Schedule trigger is available for editing and works fine.
160 character limit for 1600 character resource (sending text messages)
According to your documentation (https://www.twilio.com/docs/api/rest/sending-messages) text messages using the most recent Twilio API have a size limit of 1600 characters. However whenever I try to send a message over 160 characters (the old limit supposedly) I receive the following error: "message": "The message body exceeds the 160 character limit.", "code":21605", "moreInfo":"https://www.twilio.com/docs/errors/21605" I am using the nodeJS helper library and making the exact same call as the documentation described (again https://www.twilio.com/docs/api/rest/sending-messages)). Is it possible the Twilio nodeJS library is using the old API call and the documentation is incorrect?
Missing required key 'Bucket' in params
This is a Bug Report Description I am getting following error when run `serverless deploy -v` [code block] Current `serverless.yml` [code block] I am not using anything related bucket than why i need to setup bucket key ?
[BUG] Regression: array items[0,1] must be unique starting from 2.24.1
Description As per the subject, starting from 2.24.1, I am encountering this issue when there are overrides. Steps To Reproduce Create 2 files: 1. docker-compose.yaml [code block] 1. docker-compose.override.yaml [code block] WIth 2.23.3: [code block] With 2.24.1: [code block] Compose Version [code block] Docker Environment [code block] Anything else? _No response_
Proposal: Explicitly set HNSW build workers
Problem Selecting parallel workers for HNSW follows a similar method to IVFFLAT, i.e. leveraging the PostgreSQL `plan_create_index_workers` function, which uses the number of heap (table) pages return from `estimate_rel_size` to determine the number of parallel workers to use. This makes sense for B-tree / IVFFLAT as the time spent is in the loading the data from the table vs. calculations. But for HNSW, we're likely underestimating the number of workers we could use to speed up the builds as the HNSW process is much more CPU heavy. For example, review the [charts in this blog post][1] that show how we can increase concurrent inserts and can continue scaling the amount of inserts per second. We can see this play out in practice. Using a similar sample to [aforementioned blog post][1] on a 64-core m7gd.16xlarge instance, I created a table with 1,000,000 128-dim vectors. With enabling parallel builds, PostgreSQL elected to spawn 4 parallel workers (+ leader). [code block] For the same data set, I hardcoded to use 8 parallel workers (+leader), and saw a significant speedup: [code block] We're still likely falling to [underestimating parallel workers due to TOAST][2], but this case is not affected by that as a 128-dim vector is not TOAST'd. Additionally, as mentioned, HNSW index builds are CPU bound, so we'd want to maximize the number of cores we can use for the process. (There's still considerations around shared/temporary memory, but I'm seeing the brunt of the issue a
[Question]Need help with the pgvector Installation with pgAdmin & version mismatch error
Hello, I have installed 'pgAdmin 4 v8.2' on macOS. After successfully installing the software, I proceeded to run the command CREATE EXTENSION vector; However, I encountered an error: so I attempted to solve the issue by using the following commands in my terminal: `cd /tmp git clone --branch v0.5.1 https://github.com/pgvector/pgvector.git cd pgvector make make install ` The error is still the same, i've tried `brew install pgvector`too. In the folder "pgvector", I also tried this line of command `export PG_CONFIG=/Library/PostgreSQL/16/bin/` and copy "pgvector/sql/vector--0.5.1.sql" and "vector.control" into the folder "extension" <img width="730" alt="Screenshot 2024-01-15 at 16 26 26" src="https://github.com/pgvector/pgvector/assets/74989793/40a29e2d-0824-4a88-9cf8-d7444b0066af"> Unfortunately, the error evolved to I am reaching out for assistance. Could anyone provide guidance or insights into resolving this matter? Thanks
Transpiling for Ionic
Hi, As talked in https://github.com/typeorm/typeorm/issues/890 I had an error when transpiling for Ionic. I thought your solution of adding ` "typeRoots": [ "node_modules/@types" ],` in tsconfig.json file worked for me. But I have realized that what really had worked , was to add an import inside typeorm module. I added: `import "@types/node"` to file "typeorm/driver/mongodb/MongoConnectionOptions.d.ts" So do you think only adding that modification to tsconfig.json should work?
{ useUnifiedTopology: true } leads to MongoDB connection error: MongoTimeoutError: Server selection timed out after 30000 ms
*Do you want to request a feature or report a bug? A bug. What is the current behavior? After updating to Mongoose 5.7.1, the following warning appeared: [code block] I added `useUnifiedTopology: true` to my mongoose config object as suggested by the message, even though I'm not using MongoDB replica set or sharded cluster. Here is how I configure and connect using mongoose: [code block] and here is where I used this `mongo.options` object: [code block] The warning is gone but the issue is that mongoose is now no longer able to connect: [code block] Here is how I run MongoDB using docker during development: [code block] If the current behavior is a bug, please provide the steps to reproduce. See above What is the expected behavior? Mongoose should remove the deprecation warning and run fine when using `useUnifiedTopology: true` as mongoose suggests. What are the versions of Node.js, Mongoose and MongoDB you are using? Note that "latest" is not a version.* Node: v10.16.2 Mongoose: 5.7.1 (latest) MongoDB: db version v4.2.0 Related issues: - https://github.com/Automattic/mongoose/issues/8156 - https://github.com/Automattic/mongoose/issues/8169
Specify event.data.object as an alternative
`event.data.object` is currently specified as an empty interface, which seems invalid. My understanding of the API is that it should be an alternative of all possibilities. Relevant code: https://github.com/stripe/stripe-node/blob/b2d32ef3a987b3c740bbc44c99a8209a92c3a5ee/types/2019-12-03/Events.d.ts#L56-L66