All Issues
24,993 verified issues
[BUG] docker endpoint for "default" not found
Description when building Dockefile with docker compose [code block] got this error docker endpoint for "default" not found but if i try to build with a remote docker image compose works fine. github repo: https://github.com/milon27/hello-docker.git Steps To Reproduce 1. clone this repo https://github.com/milon27/hello-docker.git 2. run [code block] 3. you should get docker endpoint for "default" not found this error os: windows 10 docker desktop version: 4.13.0 note: it was fine when I update the docker desktop to the latest version this problem started. Compose Version [code block] Docker Environment [code block] Anything else? Error screenshot
Support for Binary Quantization
Would love to see this capability in pgvector: https://qdrant.tech/articles/binary-quantization/ Essentially, BQ converts any vector embedding of floating point numbers into a vector of binary or boolean values. > In exchange for reducing our 32 bit embeddings to 1 bit embeddings we can see up to a 40x retrieval speed up gain! > One of the reasons vector search still works with such a high compression rate is that these large vectors are over-parameterized for retrieval. This is because they are designed for ranking, clustering, and similar use cases, which typically need more information encoded in the vector.
CORS error No 'Access-Control-Allow-Origin' header is present on the requested resource
Hello, this is my request: ` axios({ method: 'POST', url: `${SERVER_ADDRESS}/api/v1/manager/restaurant/${restaurantName}/payment-methods`, crossDomain: true, data: { payment_methods: checkedPayments }, }) .then(() => { dispatch(loadPayments(restaurantName)); }).catch((error) => { console.log(error); dispatch(paymentsError()); }); ` the server is laravel 5, it is responding with: `XMLHttpRequest cannot load http://localhost:8000/api/v1/manager/restaurant/accusamus/payment-methods. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access.` Server headers are set with CORS middleware like this: return $next($request) ->header("Access-Control-Expose-Headers", "Access-Control-") ->header("Access-Control-Allow-Headers", "Access-Control-, Origin, X-Requested-With, Content-Type, Accept") ->header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS, HEAD') ->header('Access-Control-Allow-Origin', '') ->header('Allow', 'GET, POST, PUT, DELETE, OPTIONS, HEAD'); Theese are the response headers, which I get when I use postman: Access-Control-Allow-Headers →Access-Control-, Origin, X-Requested-With, Content-Type, Accept Access-Control-Allow-Methods →GET, POST, PUT, DELETE, OPTI
[RFC] Dynamic Routes
Dynamic Routes Background Dynamic routing (also known as URL Slugs or Pretty/Clean URLs) has been a long-time requested feature of Next.js. Current solutions involve placing a L7 proxy, custom server, or user-land middleware in-front of your application. None of these solutions offer a sufficiently _ergonomic_ developer experience. Additionally, users reaching for a custom server inadvertently opt-out of advanced framework-level features like per-page serverless functions. Goals 1. Leverage convention to provide URL Slug support that is easy to reason about 2. Cover a majority of use-cases observed in the wild 3. Eliminate the need of a custom server to support `/blog/:post` 4. Validate `<Link />` route transitions when possible 5. Avoid an implementation that requires a route manifest 6. Routes must be expressible through the filesystem Proposal Next.js should support named URL parameters that match an entire URL segment. These routes would be expressed via the filesystem: 1. A filename or directory name that is wrapped with `[]` would be considered a named parameter 2. Explicit route segments would take priority over dynamic segments, matched from left-to-right 3. Route parameters would be required, never optional 4. Route parameters will be merged into the `query` object (accessible from `getInitialProps` or `router` via `withRouter`) — these parameters can not be overridden by a query parameter To help understand this proposal, let's examine the following file t
API client lacks a messages attribute
👋 I'm trying to use the Claude API and I can't even get the client to work properly following the SDK example to the character. Anything I'm doing wrong? <img width="646" alt="image" src="https://github.com/anthropics/anthropic-sdk-python/assets/55989773/2d2da778-7c4e-4328-86db-e57da305a619">
Tailwind 2.0 poor performance as part of a webpack PostCSS build system
Description of the problem Tailwind CSS 2.0 builds slowly as part of a HMR webpack build system. It is slower than the release, but that could just be due to the amount of CSS generated increasing. I filed a very similar issue a month ago https://github.com/tailwindlabs/tailwindcss/issues/2544 and worked around the problem by splitting the CSS up into separate chunks. Global `@apply` still worked, and everything was great. It's all written up in the article Speeding Up Tailwind CSS Builds However with Tailwind CSS 2.0, the technique described in the article breaks. Desired solution I'm hoping to have the DX of working with Tailwind CSS 2.0 be improved from a HMR build time perspective. I realize that you can only optimize your generation of CSS so much, and a PR is in the works to do just that with `esbuild`. I also realize that part of the slowness here is simply webpack and the surrounding ecosystem being slow when dealing with massive amounts of CSS (though I've optimized that quite a bit here). However, the paradigm that Tailwind CSS is using is what generates a massive amount of CSS, and webpack is a very widely used tool that many things are built upon. Some way to address the DX here would be great; huge gains can be made using the CSS splitting technique described in the article, maybe there could be a way to restore that functionality to Tailwind 2.x? Link to a minimal reproduction: I made a new branch with Tailwind 2.0, webpack 5, PostCSS 8, and all the g
No way to get requested fields of the object inside `resolve`
Let's say I have a Database with User entity with a lot of fields: [code block] And I have a GraphQL: [code block] And I do a GraphQL query to get `name` of all `users` [code block] I don't want to fetch all the fields from the database. I want to know what fields to fetch... Is there any way to get a list of fields that were requested in `resolve` method?
CVE-2023-45857 (CWE-359) XSRF-TOKEN value is disclosed to an unauthorised actor
Describe the bug Hi team, @jasonsaayman and @DigitalBrainJS, The library inserts the X-XSRF-TOKEN header using the secret XSRF-TOKEN cookie value in all requests to any server when the XSRF-TOKEN cookie is available, and the withCredentials setting is turned on. If a malicious user manages to obtain this value, it can potentially lead to the XSRF defence mechanism bypass. It's crucial to ensure the protection of CSRF tokens. These tokens should be treated as confidential information and managed securely at all times. You may check it here: https://portswigger.net/web-security/csrf/preventing https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html Type of vulnerability: CWE-359: Exposure of Private Personal Information to an Unauthorized Actor Severity: High (7.1) CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N To Reproduce 1) Start a new project using the latest version of Next.js by running the following command: `npx create-next-app@latest`. Then, install the latest version of the Axios library with this command: `npm i axios` 2) Create an Axios instance with the following configuration, which enables cross-site request forgery (CSRF) protection by including credentials in requests: [code block] 3) Install the XSRF-TOKEN cookie with specific attributes. Set the cookie value "whatever" and configuring it for the "localhost" domain with strict same-site policy: [code block] 4) Initiate a cross-domain request using your Axios
[BUG]: In the Query API generated identifier exceeds 63-bytes length limit
What version of `drizzle-orm` are you using? 0.28.6 What version of `drizzle-kit` are you using? 0.19.13 Describe the Bug I have a query using Query API that is doing a lot of nested joins. I've chcecked the generated query and it appears that the generated identifier name is getting truncated because it's too long. From what I read Postgres has a limit of 63-bytes long identifiers. Here is the generated query (I've replaced params with actual values): [code block] And the error says: [code block] Expected behavior When identifier length is too long it should try to maybe generate acronyms of tables. Instead of `training_step_templates` maybe it should use `tst` or maybe even random names to avoid conflicts. Environment & setup _No response_
[serverless] Connection Reuse is broken in a Lambda environment
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` [ ] `expo` TypeORM version: [x] `latest` [ ] `@next` [ ] `0.x.x` (or put your version here) Steps to reproduce or a small repository showing the problem: I'm primarily expanding further on https://github.com/typeorm/typeorm/issues/2598#issue-345445322, the fixes described there are catastrophic in nature, because: 1. They either involve closing connections without understanding that the lambda may not just be serving that one request. 2. Full bootstrap of the connection a second time anyway (defeating the purpose of caching it in the first place)) and I believe this is something that should be addressed in core. 3. Even the somewhat saner metadata rebuild causes problems (since it cannot be awaited and runs in parallel). This results in metadata lookups while queries are running (for another controller, perhaps) randomly start failing. The issue is exactly as described, if we attempt to reuse connections in a lambda environment, the entity manager no longer seems to know anything about our entities. The first request made completes successfully (and primes our connection manager to reuse the same connection). Subsequent requests quit with `RepositoryNotFoundError: No repository for "TData" was found. Looks like this entity is
Data Only Containers/No Run Containers
I propose that Compose be able to support a way to create volume containers that never run. Right now, if you want to describe a volume container in your figfile, you must expect it to run. The best you can do is [code block] But it shouldn't be necessary to run a DVC at all. In the commandline Docker client I can do: [code block] It's admittedly a little strange to have to provide an entrypoint to `scratch`, but it doesn't ever run, so it doesn't make a difference. It would be nice to be able to do this in Compose as well. [code block] Related: - #697 asks to be able to run a subset of containers. This is similar in that it asks not to run a container. Perhaps this provides a use case for that, but that issue still implies that the containers can be run. This proposal is to mark containers for creation, but never to run them. - #613 - Despite the similar title this is a feature request with significantly different implications.
[BUG]: `drizzle.config.ts` doesn't follow `tsconfig.json` for module path aliases (`@/app/lib/env`) but works for absolute paths (`./src/app/lib/env`)
What version of `drizzle-orm` are you using? ^0.28.6 What version of `drizzle-kit` are you using? ^0.19.13 Describe the Bug if i import using `'@/app/lib/env'`, it doesn't work but if i import using `'./src/app/lib/env'`, it works. for example, this works fine: drizzle.config.ts [code block] but the following throws an error `Error: Cannot find module '@/app/lib/env'`: drizzle.config.ts [code block] my `env` file looks like this: lib/env.ts [code block] Expected behavior this should work. drizzle.config.ts [code block] Environment & setup windows 10! my tsconfig looks like: tsconfig.json [code block]
Could not resolve @prisma/client despite the installation that we just tried.
Bug description I've come back to work on a product again after a couple of weeks and it broke (again) which I guess just happens as prisma is evolving quickly but this one I couldn't figure out the fix. Locally, it generates fine still, but in the Docker image which our backend deploys it throws this after `yarn dlx prisma generate` [code block] (Which I tried and doesn't make any difference) I also tried installing prisma globally with `npm i -g prisma` and the same issue occurs. Same with `npx prisma generate` too. `npx prisma` results in this: [code block] I did manage to get it to work once by running the yarn dlx command twice, but I can't remember how, it's been a few hours now! Are there any specific changes that happened in the last few weeks that I need to make changes for? One aspect of this project is that it's a multi-tenant yarn workspaces repo with a few different packages inside, but the root package includes `prisma` as a dependency and `@prisma/client` as a dev dependency (which I'm not sure why, I think it solved another similar issue a couple of months back) How to reproduce It's probably project specific, but just running generate triggers it. Expected behavior _No response_ Prisma information Schema isn't relevant. It generates fine on development machine (mac) Environment & setup - OS: Building a Docker image (based on `golang:latest`) - Node.js version: 12.18.3 Prisma Version [code block]
RFC: Extra property on field definition to pass extra metadata
I'm currently adding extra properties to some graphql object field definitions, like the following: [code block] And then using them later on via the `info` argument inside some middlewares (using `graphql-middleware`): [code block] For more details, see the following medium post: graphql mutation arguments validation using yup --- The thing is, this is relying on internal behavior. The following code spreads all properties given to the field: https://github.com/graphql/graphql-js/blob/81719749e01f030cfb3a01a97e7e4bfc534bb08f/src/type/definition.js#L720-L724 Is that something expected to not change? If yes, then no need for any other extra property or for this issue. 😄 But if this is something that can change in future versions, I would love the possibility of having an extra field for that extra metadata. I'm available to work on adding this, if it's approved.
github context is not accessible from step.uses
Describe the bug It is not possible to use `github` context in `jobs.<job_id>.steps[*].uses`. To Reproduce create workflow which uses `github` context within `uses`: [code block]` Expected behavior `github.repository` and `github.sha` are substituted with correspoonding values. Runner Version and Platform public runner What's not working? `github` context variable substitution Job Log Output [code block]` Runner and Worker's Diagnostic Logs https://github.com/myci-actions/add-deb-repo/actions/runs/469160309
docker-compose build hangs
[code block] I'm trying to use `docker-compose build` but the command hangs: [code block] docker-compose.yml contains [code block] and go/.dockerignore has [code block] The same invocation via `docker build` completes in about a minute: [code block] Any idea what's going on here?
AxiosRequestHeaders type breaks from 0.21.4 to 0.22.0
Describe the bug The type has changed and now I am getting linting errors on a working code. I get _Element implicitly has an 'any' type because index expression is not of type 'number'.ts(7015)_ error when I try to access the headers by their name on a `AxiosRequestHeaders` object. For example accessing a common header in `transfomRequest` where the content of headers is: If I try to access the common _Accept_ header key, then I will get the above error. I think the issue is at: https://github.com/axios/axios/blob/1025d1231a7747503188459dd5a6d1effdcea928/index.d.ts#L3 The type should be: [code block] Possibly the `AxiosResponseHeaders` has the same issue. To Reproduce [code block] Expected behavior Expected to not raise an error there Environment - Axios 0.23.0 - TypeScript 4.4.4 Additional context/Screenshots
Add ARM + MacOS target to be able to use on self-hosted runners
Describe the enhancement A new architecture+OS build target to enable adding runners on the new Apple Silicon (ARM) Macs. Additional information This would be useful both for GitHub-hosted and self-hosted runners. I have no idea how much work would be necessary :)
'Could not encrypt/decrypt the value for SecureStore' error on android app
Minimal reproducible example https://snack.expo.dev/@simranjits11/error-with-securestorage Summary Context When trying to get item using `await SecureStore.getItemAsync('mobile')`. It throws an error saying `Could not encrypt/decrypt the value for SecureStore`. The error is very device specific and happens occasionally. - Message: Error: Could not encrypt/decrypt the value for SecureStore . - SDK: 47.0.12 - Device: OnePlus 8T (Android 13) Stack Trace [code block] Environment expo-env-info 1.0.5 environment info: System: OS: macOS 13.3.1 Shell: 5.9 - /bin/zsh Binaries: Node: 18.14.2 - ~/.nvm/versions/node/v18.14.2/bin/node Yarn: 1.22.19 - /opt/homebrew/bin/yarn npm: 9.6.7 - ~/Documents/Projects/realmagic/node_modules/.bin/npm Watchman: 2023.02.20.00 - /opt/homebrew/bin/watchman Managers: CocoaPods: 1.11.3 - /Users/simranjitsingh/.rbenv/shims/pod SDKs: iOS SDK: Platforms: DriverKit 22.4, iOS 16.4, macOS 13.3, tvOS 16.4, watchOS 9.4 IDEs: Android Studio: 2020.3 AI-203.7717.56.2031.7678000 Xcode: 14.3/14E222b - /usr/bin/xcodebuild npmPackages: react: 18.1.0 => 18.1.0 react-dom: 18.1.0 => 18.1.0 npmGlobalPackages: eas-cli: 3.15.0 expo-cli: 6.3.2 Expo Workflow: managed
Connecting to an Azure Redis Cluster with TLS not working
I've been trying to connect to a Redis three node cluster in Azure using ioredis When I connect using the Redis.Cluster constructor: [code block] The error I get is: [code block] When I connect using a non-cluster Redis connection: [code block] The error I get is: [code block] As you can see it is using TLS on port 6380. Azure provides me with one host+port combination and two different access-keys (primary/seconday) - which I find weird, which access-key should I use? Also I'm not sure if I should be connecting in Cluster mode, but I'd prefer to to gain the benefits of clustering. When I do it appears it tries to find the slots at `127.0.0.1:6380` which is probably not correct. In Azure's quickstart they connect using node_redis with: [code block] I was hoping someone here would have come across the same issue and solved it. Thanks! [1]: https://github.com/luin/ioredis