Wasp•4d ago

Getting CORS issue when using Wasp CLI to deploy

@kapa.ai I'm experiencing a CORS issue, NOT using my own domain:

Access to XMLHttpRequest at 'https://skyblaze-server.fly.dev/crud/Slot/get-all' from origin 'https://skyblaze-client.fly.dev' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Access to XMLHttpRequest at 'https://skyblaze-server.fly.dev/crud/Slot/get-all' from origin 'https://skyblaze-client.fly.dev' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

My main.wasp is like

  server: {
    setupFn: import setup from "@src/serverSetup",
    middlewareConfigFn: import { serverMiddlewareFn } from "@src/serverSetup"
  },

  server: {
    setupFn: import setup from "@src/serverSetup",
    middlewareConfigFn: import { serverMiddlewareFn } from "@src/serverSetup"
  },

And my src/serverSetup.ts:

 import bodyParser from 'body-parser';
import cors from 'cors';
import { type MiddlewareConfigFn } from 'wasp/server';

export default function setup() {
  console.log('Server setup running...');
}

export const serverMiddlewareFn: MiddlewareConfigFn = (middlewareConfig) => {
  middlewareConfig.set('express.json', bodyParser.json({ limit: '10mb' }));
  middlewareConfig.set('cors', cors({ origin: ['http://localhost:3000', 'https://skyblaze-client.fly.dev'] }));
  return middlewareConfig;
};

 import bodyParser from 'body-parser';
import cors from 'cors';
import { type MiddlewareConfigFn } from 'wasp/server';

export default function setup() {
  console.log('Server setup running...');
}

export const serverMiddlewareFn: MiddlewareConfigFn = (middlewareConfig) => {
  middlewareConfig.set('express.json', bodyParser.json({ limit: '10mb' }));
  middlewareConfig.set('cors', cors({ origin: ['http://localhost:3000', 'https://skyblaze-client.fly.dev'] }));
  return middlewareConfig;
};

(My client URL is https://skyblaze-client.fly.dev). Seems the CORS settings do work on my local machine since when I removed http://localhost:3000, it also throws a CORS error locally. I'm wondering whether there're something wrong in my serverSetup and middleware that causing this issue?

16 Replies

kapa.ai•4d ago

Hi @William Jin. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Based on the information provided in the knowledge sources, it appears that your CORS configuration is not being applied correctly when deployed. Let's address this issue step by step: 1. First, it's important to note that Wasp uses environment variables to configure CORS for deployed applications. As mentioned in the Deploying Manually (https://wasp-lang.dev/docs/advanced/deployment/manually#environment-variables) documentation, you need to set the WASP_WEB_CLIENT_URL environment variable on your server deployment. This variable should contain the URL of your client application. 2. For your case, you should set:

   WASP_WEB_CLIENT_URL=<https://skyblaze-client.fly.dev>

   WASP_WEB_CLIENT_URL=<https://skyblaze-client.fly.dev>

on your Fly.io server deployment. 3. The custom middleware configuration you've provided in serverSetup.ts might be overriding Wasp's default CORS configuration. While this approach can work locally, it might not be the best for deployment scenarios. 4. Instead of using a custom middleware configuration, you could try removing it and relying on Wasp's built-in CORS handling. Remove the server block from your main.wasp file and the serverSetup.ts file. 5. If you still need custom middleware for other purposes (like the bodyParser configuration), you can keep the server block but remove the CORS-specific part:

   import bodyParser from 'body-parser';
   import { type MiddlewareConfigFn } from 'wasp/server';

   export default function setup() {
     console.log('Server setup running...');
   }

   export const serverMiddlewareFn: MiddlewareConfigFn = (middlewareConfig) => {
     middlewareConfig.set('express.json', bodyParser.json({ limit: '10mb' }));
     return middlewareConfig;
   };

   import bodyParser from 'body-parser';
   import { type MiddlewareConfigFn } from 'wasp/server';

   export default function setup() {
     console.log('Server setup running...');
   }

   export const serverMiddlewareFn: MiddlewareConfigFn = (middlewareConfig) => {
     middlewareConfig.set('express.json', bodyParser.json({ limit: '10mb' }));
     return middlewareConfig;
   };

6. If you need more control over CORS settings, you can use the apiNamespace feature as described in the Making Sure CORS Works (https://wasp-lang.dev/docs/advanced/apis#making-sure-cors-works) documentation. This allows you to apply CORS settings to specific API routes. 7. Lastly, ensure that you've properly set up your deployment as described in the Deploying with the Wasp CLI (https://wasp-lang.dev/docs/advanced/deployment/cli#using-a-custom-domain-for-your-app) documentation. Even though you're not using a custom domain, the steps for setting up the environment variables are still relevant. If after applying these changes you're still experiencing CORS issues, it might be worth checking your Fly.io configuration to ensure that the environment variables are correctly set and that there are no conflicting settings. Remember, CORS issues can be tricky to debug, especially in deployed environments. If the problem persists, you might need to inspect the network requests in your browser's developer tools to see exactly what headers are being sent and received. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @William Jin, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

William JinOP•4d ago

@kapa.ai Changed my serverSetup.ts to your code:

   import bodyParser from 'body-parser';
   import { type MiddlewareConfigFn } from 'wasp/server';

   export default function setup() {
     console.log('Server setup running...');
   }

   export const serverMiddlewareFn: MiddlewareConfigFn = (middlewareConfig) => {
     middlewareConfig.set('express.json', bodyParser.json({ limit: '10mb' }));
     return middlewareConfig;
   };

   import bodyParser from 'body-parser';
   import { type MiddlewareConfigFn } from 'wasp/server';

   export default function setup() {
     console.log('Server setup running...');
   }

   export const serverMiddlewareFn: MiddlewareConfigFn = (middlewareConfig) => {
     middlewareConfig.set('express.json', bodyParser.json({ limit: '10mb' }));
     return middlewareConfig;
   };

But didn't work. Still got CORS error.

kapa.ai•4d ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- I apologize, but I don't have enough context to provide a complete answer based solely on your statement "Changed my serverSetup.ts to your code:". It seems like you might have intended to share more information or ask a specific question about the changes you made. To better assist you, could you please provide more details about: 1. The exact changes you made to your serverSetup.ts file 2. Any specific issues or questions you have after making these changes 3. Whether you're still experiencing CORS issues or if you've encountered any new problems Once you provide more information, I'll be able to give you a more accurate and helpful response based on the knowledge sources available about Wasp. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @William Jin, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

William JinOP•4d ago

@kapa.ai Client still show CORS error even after I removed all the middleware codes. Maybe not CORS problem? When I check server logs on Fly.io, it says “ [PC01] instance refused connection. is your app listening on 0.0.0.0:80? make sure it is not only listening on 127.0.0.1 (hint: look at your startup logs, servers often print the address they are listening on)”

kapa.ai•4d ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Based on the new information you've provided, it seems that the issue might not be related to CORS after all. The error message from Fly.io suggests that there's a problem with your server configuration. Let's address this: 1. The error message "instance refused connection. is your app listening on 0.0.0.0:80?" indicates that Fly.io is unable to connect to your server application. This could explain why you're seeing CORS errors on the client side, as the server is not responding at all. 2. Wasp applications deployed on Fly.io should automatically be configured to listen on the correct address and port. However, it seems that this might not be happening in your case. To troubleshoot this issue: 1. First, make sure you've set the correct environment variables for your server deployment. As mentioned in the Deploying Manually (https://wasp-lang.dev/docs/advanced/deployment/manually#environment-variables) documentation, you need to set: - PORT: The server's HTTP port number (default is 3001, but Fly.io might expect it to be 80) - WASP_WEB_CLIENT_URL: The URL of your client application - WASP_SERVER_URL: The URL where the server is running 2. You can set these environment variables using the Wasp CLI. For example:

   wasp deploy fly cmd --context server secrets set PORT=80
   wasp deploy fly cmd --context server secrets set WASP_WEB_CLIENT_URL=<https://skyblaze-client.fly.dev>
   wasp deploy fly cmd --context server secrets set WASP_SERVER_URL=<https://skyblaze-server.fly.dev>

   wasp deploy fly cmd --context server secrets set PORT=80
   wasp deploy fly cmd --context server secrets set WASP_WEB_CLIENT_URL=<https://skyblaze-client.fly.dev>
   wasp deploy fly cmd --context server secrets set WASP_SERVER_URL=<https://skyblaze-server.fly.dev>

3. After setting these variables, try redeploying your application:

   wasp deploy fly deploy

   wasp deploy fly deploy

4. If the issue persists, you might need to check your fly.toml file (if you have one) to ensure it's not overriding any of these settings. 5. As a last resort, you might want to try ejecting your Wasp app (using wasp eject server) to get full control over the server configuration. However, this should only be done if absolutely necessary, as it makes it harder to maintain your app and benefit from Wasp updates. If after trying these steps you're still encountering issues, it might be helpful to share more details about your deployment process and any custom configurations you might have. Remember, the CORS error you're seeing on the client side is likely a symptom of the server not responding at all, rather than a CORS configuration issue. Once we get the server running correctly, the CORS errors should resolve themselves if you're using Wasp's default configuration. Deploying Manually (https://wasp-lang.dev/docs/advanced/deployment/manually#environment-variables) ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @William Jin, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

NEROX•4d ago

Have you deployed the variables with the server?

William JinOP•4d ago

Thanks, I tried again and added PORT=80 and the issue seems to be fixed 🙂

Filip•3d ago

Glad you got it working! Yes, port is also a part of the origin. The full origin is (protocol, domain, port), and all three must match to avoid cors errors

William JinOP•6h ago

@kapa.ai I encountered the issue again after a few more deployments… I'm pretty sure I didn't mess up server configs (I changed my client URL to admin.skyblaze.app yesterday and it worked, so the WASP_WEB_CLIENT_URL should be fine.) However when I deploy again today, I got

[error] [PC01] instance refused connection. is your app listening on 0.0.0.0:80? make sure it is not only listening on 127.0.0.1 (hint: look at your startup logs, servers often print the address they are listening on)

2024-12-21T10:37:45.623 proxy[4d8952eb462638] hkg [error] [PR04] could not find a good candidate within 21 attempts at load balancing

2024-12-21T10:38:08.958 app[6830d4ec7560e8] sjc [info] Datasource "db": PostgreSQL database "skyblaze_server", schema "public" at "skyblaze-db.flycast:5432"

2024-12-21T10:38:12.638 app[6830d4ec7560e8] sjc [info] 22 migrations found in prisma/migrations

2024-12-21T10:38:13.846 app[6830d4ec7560e8] sjc [info] Error: P3009

2024-12-21T10:38:13.846 app[6830d4ec7560e8] sjc [info] migrate found failed migrations in the target database, new migrations will not be applied. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve

2024-12-21T10:38:13.846 app[6830d4ec7560e8] sjc [info] The `20240726163858_` migration started at 2024-12-21 08:51:13.198206 UTC failed

[error] [PC01] instance refused connection. is your app listening on 0.0.0.0:80? make sure it is not only listening on 127.0.0.1 (hint: look at your startup logs, servers often print the address they are listening on)

2024-12-21T10:37:45.623 proxy[4d8952eb462638] hkg [error] [PR04] could not find a good candidate within 21 attempts at load balancing

2024-12-21T10:38:08.958 app[6830d4ec7560e8] sjc [info] Datasource "db": PostgreSQL database "skyblaze_server", schema "public" at "skyblaze-db.flycast:5432"

2024-12-21T10:38:12.638 app[6830d4ec7560e8] sjc [info] 22 migrations found in prisma/migrations

2024-12-21T10:38:13.846 app[6830d4ec7560e8] sjc [info] Error: P3009

2024-12-21T10:38:13.846 app[6830d4ec7560e8] sjc [info] migrate found failed migrations in the target database, new migrations will not be applied. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve

2024-12-21T10:38:13.846 app[6830d4ec7560e8] sjc [info] The `20240726163858_` migration started at 2024-12-21 08:51:13.198206 UTC failed

kapa.ai•6h ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Based on the error logs you've provided, it seems that you're facing two distinct issues: 1. Server Connection Refusal 2. Failed Database Migration Let's address these issues one by one: 1. Server Connection Refusal: The error "instance refused connection. is your app listening on 0.0.0.0:80?" suggests that your server is not properly binding to the expected port. This could be due to a configuration issue or a problem with how the server is starting up. To troubleshoot this: - Double-check that the PORT environment variable is set correctly on Fly.io. You can verify this by running:

     wasp deploy fly cmd --context server secrets list

     wasp deploy fly cmd --context server secrets list

- Ensure that the PORT is set to 80, as Fly.io expects your app to listen on this port. 2. Failed Database Migration: The more critical issue seems to be the failed database migration. The error message indicates that there are failed migrations in your target database, which is preventing new migrations from being applied. To resolve this:
a. First, try to understand why the migration failed. The error mentions a specific migration: 20240726163858_. Look at this migration file in your prisma/migrations folder to see what changes it was trying to make. b. You might need to manually resolve the failed migration. As suggested in the Migrating from SQLite to PostgreSQL (https://wasp-lang.dev/docs/data-model/backends#migrating-from-sqlite-to-postgresql) documentation, you could try the following steps: 1. Delete all the old migrations:

         rm -r migrations/
         wasp clean

         rm -r migrations/
         wasp clean

2. Ensure your database is running. 3. Run wasp db migrate-dev to create a new initial migration. c. If the above doesn't work, you might need to manually fix the database schema or data that's causing the migration to fail. This could involve connecting directly to your production database and making the necessary changes. d. As a last resort, if your app is still in development and you don't mind losing data, you could consider dropping the database and starting fresh. However, be extremely cautious with this approach in a production environment. After resolving the migration issue, try deploying your app again:

wasp deploy fly deploy

wasp deploy fly deploy

If you continue to face issues, you might want to consider reaching out to the Wasp community on their Discord server (https://discord.gg/rzdnErX) for more specific help, as mentioned in several of the support threads in the knowledge sources. Remember, when dealing with database migrations in a production environment, it's crucial to be cautious and have a backup of your data before making any changes. Migrating from SQLite to PostgreSQL (https://wasp-lang.dev/docs/data-model/backends#migrating-from-sqlite-to-postgresql) ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @William Jin, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

William JinOP•6h ago

@kapa.ai still having the issue. how to fix the migration issues in my production database?

kapa.ai•6h ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- To address the migration issues in your production database, you'll need to take a careful and systematic approach. Based on the information from the knowledge sources and our previous conversation, here are the steps you can follow: 1. First and foremost, make sure to back up your production database before attempting any fixes. This is crucial to prevent data loss. 2. As mentioned in the Migrating from SQLite to PostgreSQL (https://wasp-lang.dev/docs/data-model/backends#migrating-from-sqlite-to-postgresql) documentation, you can try the following steps: a. Delete all the old migrations locally:

      rm -r migrations/
      wasp clean

      rm -r migrations/
      wasp clean

b. Run wasp db migrate-dev locally to create a new initial migration that reflects your current schema. 3. If the above doesn't work, you might need to manually resolve the failed migration in your production database. The error message you received earlier mentioned a specific migration: 20240726163858_. You should: a. Examine this migration file in your prisma/migrations folder to understand what changes it was trying to make.
b. Connect to your production database directly (you can use fly postgres connect -a <your-db-name> as mentioned in a Discord support thread (https://discord.com/channels/686873244791210014/1217295340785635418)).
c. Manually apply the changes that the failed migration was attempting to make, or fix any issues preventing the migration from completing. 4. After manually fixing the database, you might need to mark the migration as applied in your production database. You can do this by inserting a record into the _prisma_migrations table. 5. If you're still having issues, you might need to use Prisma's migrate diff and db execute commands, which were mentioned in a GitHub issue comment (https://github.com/wasp-lang/wasp/issues/215). These commands can help you generate and apply the necessary SQL to bring your production database in line with your schema. 6. As a last resort, if your app is not yet in production or you can afford to lose data, you could consider dropping the database and starting fresh. However, this should only be done if absolutely necessary and after careful consideration. 7. After resolving the migration issues, redeploy your app using:

   wasp deploy fly deploy

   wasp deploy fly deploy

Remember, dealing with production database migrations can be tricky and potentially risky. If you're not comfortable making these changes or if the problem persists, it might be best to seek help from the Wasp community on their Discord server (https://discord.com/channels/686873244791210014/1217295340785635418), where you can get more specific guidance tailored to your situation. Migrating from SQLite to PostgreSQL (https://wasp-lang.dev/docs/data-model/backends#migrating-from-sqlite-to-postgresql) Discord support thread (https://discord.com/channels/686873244791210014/1217295340785635418) ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @William Jin, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

William JinOP•6h ago

@kapa.ai In fact I didn't change my db schema recently. How do I check what cause the db migration filed and how should I fix it?

The `20240726163858_` migration started at 2024-12-21 08:51:13.198206 UTC failed

The `20240726163858_` migration started at 2024-12-21 08:51:13.198206 UTC failed

I also opened db studio to connect to my production database and didn't find anything wrong.

kapa.ai•6h ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Based on the information you've provided and the knowledge sources available, it seems that you're facing a peculiar situation where a migration is failing without any recent schema changes. Let's explore how to investigate and potentially resolve this issue: 1. First, we need to understand why the migration is failing. The error message you've shared doesn't provide much detail about the cause of the failure. To get more information, you can try the following: a. Use the Prisma CLI to check the status of your migrations. You can do this by connecting to your production database and running:

   npx prisma migrate status

   npx prisma migrate status

This command will show you the status of all migrations, including any that have failed. 2. To connect to your production database, you can use the Fly.io CLI as mentioned in the Discord support thread (https://discord.com/channels/686873244791210014/1217295340785635418):

   fly postgres connect -a <your-db-name>

   fly postgres connect -a <your-db-name>

3. Once connected, you can examine the _prisma_migrations table to see the status of your migrations:

   SELECT * FROM _prisma_migrations ORDER BY started_at DESC LIMIT 5;

   SELECT * FROM _prisma_migrations ORDER BY started_at DESC LIMIT 5;

This will show you the most recent migrations and their status. 4. If you find that the 20240726163858_ migration is marked as failed in the _prisma_migrations table, you might need to manually mark it as applied. You can do this with an SQL command:

   UPDATE _prisma_migrations SET applied_steps_count = 1, finished_at = NOW() WHERE migration_name = '20240726163858_';

   UPDATE _prisma_migrations SET applied_steps_count = 1, finished_at = NOW() WHERE migration_name = '20240726163858_';

However, be cautious with this approach and ensure that the changes this migration was supposed to make are actually present in your database schema. 5. If marking the migration as applied doesn't resolve the issue, you might need to use Prisma's migrate diff command to compare your local schema with the production database:

   npx prisma migrate diff --from-schema-datamodel prisma/schema.prisma --to-url YOUR_PRODUCTION_DATABASE_URL

   npx prisma migrate diff --from-schema-datamodel prisma/schema.prisma --to-url YOUR_PRODUCTION_DATABASE_URL

This will show you any differences between your local schema and the production database. 6. If there are differences, you might need to manually apply them or create a new migration to resolve these differences. 7. After resolving any discrepancies, try deploying your app again:

   wasp deploy fly deploy

   wasp deploy fly deploy

Remember, working with production databases requires caution. Always backup your data before making changes, and if you're unsure about any steps, it's best to seek help from the Wasp community on their Discord server (https://discord.com/channels/686873244791210014/1217295340785635418). If these steps don't resolve the issue, or if you find unexpected differences between your local schema and the production database, you might need to investigate further. It's possible that there could be an issue with how the migrations are being applied during deployment, or there might be a mismatch between your local development environment and the production environment. Discord support thread (https://discord.com/channels/686873244791210014/1217295340785635418) ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @William Jin, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

William JinOP•5h ago

@kapa.ai postgres=# SELECT * FROM _prisma_migrations ORDER BY started_at DESC LIMIT 5; ERROR: relation "_prisma_migrations" does not exist

kapa.ai•5h ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- The error message you're seeing indicates that the _prisma_migrations table doesn't exist in your database. This is unexpected and suggests that there might be a more fundamental issue with your database setup or Prisma migrations. Let's explore this situation and potential solutions: 1. First, it's important to understand that the _prisma_migrations table is created and managed by Prisma to keep track of applied migrations. If this table is missing, it means that Prisma hasn't been able to initialize its migration system in your database. 2. This situation could occur if: - The database is completely new and no migrations have been run yet. - The migrations were run but the _prisma_migrations table was accidentally deleted. - There's a mismatch between the database you're connected to and the one your application is actually using. 3. To address this issue, you can try the following steps: a. Verify that you're connected to the correct database. You can check the current database with:

      SELECT current_database();

      SELECT current_database();

b. If you're in the correct database, you might need to reinitialize Prisma's migration system. You can do this locally by running:

      wasp db migrate-dev

      wasp db migrate-dev

This should create the initial migration and the _prisma_migrations table. c. After running this command locally, try deploying your app again:

      wasp deploy fly deploy

      wasp deploy fly deploy

4. If the problem persists after deployment, you might need to manually create the _prisma_migrations table in your production database. However, this should be done cautiously and only as a last resort. 5. Another approach, as mentioned in the Migrating from SQLite to PostgreSQL (https://wasp-lang.dev/docs/data-model/backends#migrating-from-sqlite-to-postgresql) documentation, is to start fresh: a. Locally, delete all existing migrations:

      rm -r migrations/
      wasp clean

      rm -r migrations/
      wasp clean

b. Create a new initial migration:

      wasp db migrate-dev

      wasp db migrate-dev

c. Deploy your app again:

      wasp deploy fly deploy

      wasp deploy fly deploy

Remember, these steps involve manipulating your database structure, which can be risky, especially in a production environment. Always ensure you have a backup of your data before proceeding. If these steps don't resolve the issue, or if you're uncomfortable making these changes, it would be advisable to seek help from the Wasp community on their Discord server (https://discord.com/channels/686873244791210014/1217295340785635418). They might be able to provide more specific guidance based on your particular setup and deployment configuration. Migrating from SQLite to PostgreSQL (https://wasp-lang.dev/docs/data-model/backends#migrating-from-sqlite-to-postgresql) ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @William Jin, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

Gaming

Programming

Getting CORS issue when using Wasp CLI to deploy