Description
With the following Cloudflare Worker, errors can be observed when deployed to production:
import postgres from 'postgres';
export default {
async fetch(request, env, ctx): Promise<Response> {
const connection = postgres('postgres://reader:NWDMCE5xdipIjRrp@hh-pgsql-public.ebi.ac.uk:5432/pfmegrnargs');
const results = await Promise.all([
connection`SELECT 1`,
connection`SELECT 2`,
connection`SELECT 3`,
connection`SELECT 4`,
connection`SELECT 5`,
connection`SELECT 6`,
connection`SELECT 7`,
connection`SELECT 8`,
connection`SELECT 9`,
connection`SELECT 10`,
]);
ctx.waitUntil(connection.end());
return Response.json(results);
},
} satisfies ExportedHandler<Env>;
While this works fine locally using wrangler
and workerd
, in production, they enforce 6 max connections and after deploying this worker in production, hitting it essentially results in a deadlock and errors like this:
Cloudflare documents the connection limit in their docs here: https://developers.cloudflare.com/workers/platform/limits/#simultaneous-open-connections
The solution is to simply reduce the number of max connections from 10
to 3
(to allow other things in the worker) in user config, but I imagine it would be a good idea if this is reduced by default when in Workers environment, to prevent other users hitting issues when using the default configuration in a Cloudflare Workers environment.
This has also been raised to folks at Cloudflare to see if there's anything they can improve on their end to help solve, or at least improve the debugging experience of this.
Activity
porsager commentedon Jan 31, 2025
Very good point! I think a proper default for CloudFlare is a good idea, but perhaps we should wait and see if they might change something on their end instead?
Cherry commentedon Jan 31, 2025
They're updating the docs at cloudflare/cloudflare-docs#19616, so I'm not sure if there's any planned changes on the network/runtime end, but waiting a little while to see if they do is probably a good idea.
ReppCodes commentedon Jan 31, 2025
Let me link this issue around internally with the Runtime folks, so it gets noticed.