quirrel-next
quirrel-next copied to clipboard
Getting a 500 when using deployed to production
Everything works fine in dev, however we are getting a 500 when trying to use it in production. When scheduling a task I am getting:
Error: Unexpected status: 500
at QuirrelClient.<anonymous> (/var/task/node_modules/@quirrel/client/dist/src/index.js:151:35)
at step (/var/task/node_modules/@quirrel/client/dist/src/index.js:44:23)
at Object.next (/var/task/node_modules/@quirrel/client/dist/src/index.js:25:53)
at fulfilled (/var/task/node_modules/@quirrel/client/dist/src/index.js:16:58)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
Not sure how to go about debugging this. We have the QUIRREL_TOKEN and QUIRREL_ENCRYPTION_SECRET set like the documentation says. We are setting the QUIRREL_BASE_URL to reference the VERCEL_URL so that it will work on both our preview builds and our production builds.
Could it be that you forgot to prefix the QUIRREL_BASE_URL with https:// ? I think the VERCEL_URL doesn‘t include that. I should also add better error descriptions for this, I suppose 😅
Having it directly tied to the VERCEL_URL also creates problems for the Production deployment (aka jobs will always be executed against the version that they were deployed with, even if you fixed an important bug in a newer one).
What‘s the reason you tied QUIRREL_BASE_URL to VERCEL_URL?
Ah, I see what you are saying now, I will try that.
We pretty much just want to be able to test in the preview builds that Vercel creates (they are auto-generated URLs that we do not have control of) as well as it working in production. Maybe there is a better way to do this?
I‘ll sleep over it and get back to you with an answer tomorrow.
Great, thanks! I will think on it too.
Alright! After a good night's sleep on the issue, I guess this is the way to go:
- For staging / preview deployments, use a reference to
VERCEL_URL. On these, you actually want the jobs to run against the same version that they were deployed with, and that makes sense :) - For production, put in the production URL of your service, so that it's the same for every deployment to prod. That way, prod jobs will always be run against the most current deployment - no matter in which deployment they were created. That gives you a chance to actually fix bugs ;D
I'll add a heuristic to the Quirrel client that automatically prefixes URLs with https:// if no protocol is present. That way, it will work with VERCEL_URL.
Does that sound about right for your usecase? Anything else you think I missed, that I should consider with this?
Yes, that would be fantastic! That looks like it would solve are problem.