[BUG] Duplicate calls to `initOpenNextCloudflareForDev` spawn competing workerds

[lukealbao]

Describe the bug

👋 Hi!

We had a user who mistakenly introduced two calls to initOpenNextCloudflareForDev() in their config. They got an unintelligible workerd error:

*** Fatal uncaught kj::Exception: workerd/util/sqlite.c++:842: failed: SENTRY_DO SQLite failed; NOSENTRY database is locked: SQLITE_BUSY

stack: /repo/node_modules/@cloudflare/workerd-linux-64/bin/workerd@32c316b /repo/node_modules/@cloudflare/workerd-linux-64/bin/workerd@1fe0635 /repo/node_modules/@cloudflare/workerd-linux-64/bin/workerd@202b6b2 /repo/node_modules/@cloudflare/workerd-linux-64/bin/workerd@1febbec /repo/node_modules/@cloudflare/workerd-linux-64/bin/workerd@1feb642 /repo/node_modules/@cloudflare/workerd-linux-64/bin/workerd@1fa9412 /repo/node_modules/@cloudflare/workerd-linux-64/bin/workerd@2025b5f /repo/node_modules/@cloudflare/workerd-linux-64/bin/workerd@2028eb5 /repo/node_modules/@cloudflare/workerd-linux-64/bin/workerd@1f7b289 /repo/node_modules/@cloudflare/workerd-linux-64/bin/workerd@520c535 /repo/node_modules/@cloudflare/workerd-linux-64/bin/workerd@520ca58 /repo/node_modules/@cloudflare/workerd-linux-64/bin/workerd@520a51e /repo/node_modules/@cloudflare/workerd-linux-64/bin/workerd@520a31e /repo/node_modules/@cloudflare/workerd-linux-64/bin/workerd@1f62d15 /lib/x86_64-linux-gnu/libc.so.6@27249 /lib/x86_64-linux-gnu/libc.so.6@27304 /repo/node_modules/@cloudflare/workerd-linux-64/bin/workerd@1f62024

unhandledRejection MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging output above.
at ignore-listed frames {
code: 'ERR_RUNTIME_FAILURE',
cause: undefined
}

The shouldContextInitializationRun guard protects duplicate invocations across processes, but in this scenario, both calls came from the same process.

We're happy to submit a patch if it's helpful. Two broad options I see:

1. Expose a more user friendly error.
2. Cache the initial value and return it on subsequent calls.

Steps to reproduce

import { initOpenNextCloudflareForDev } from "@opennextjs/cloudflare";

initOpenNextCloudflareForDev();
initOpenNextCloudflareForDev();

Expected behavior

An end user should be able to debug their error. If there's an invariant we can retain without their help, we do.

@opennextjs/cloudflare version

1.19.0

Wrangler version

4.82.1

next info output

Not available, sorry

Additional context

No response

[vicb]

It would be great if you can create a PR.
Option #1 looks good.

[lukealbao]

@vicb to clarify, would you like to see the hard failure + a friendly error, or no-op + friendly error?

[vicb]

@vicb to clarify, would you like to see the hard failure + a friendly error, or no-op + friendly error?

The simplest to implement is ok as long as there is a clear error message.