Default connections to less than 10 in Cloudflare Workers environment to avoid deadlock

[Cherry]

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:[email protected]: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.

[porsager]

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]

They're updating the docs at https://github.com/cloudflare/cloudflare-docs/pull/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]

Let me link this issue around internally with the Runtime folks, so it gets noticed.