fix: match NOT_LISTENING_ERROR against local-dev runtime message#230
Open
juanibiapina wants to merge 2 commits into
Open
fix: match NOT_LISTENING_ERROR against local-dev runtime message#230juanibiapina wants to merge 2 commits into
juanibiapina wants to merge 2 commits into
Conversation
The isNotListeningError helper uses .includes() to detect the error. In production the runtime returns 'The container is not listening in the TCP address ...', but in local dev (wrangler dev) it returns 'container is not listening ...' without the leading 'the'. The current constant 'the container is not listening' is not a substring of the local-dev variant, so the readiness loop never recognises the error and retries indefinitely. Shorten the constant to 'container is not listening' so it matches both variants.
Add a unit test that mocks the local-dev error message (without the leading 'the') and asserts doStartContainer returns immediately instead of retrying. The test counts fetch calls: 2 with the fix (recognised on first try), 3 without (falls through to retry).
joe345-str
approved these changes
Jun 29, 2026
prisis
added a commit
to anolilab/lunora
that referenced
this pull request
Jun 29, 2026
Move @cloudflare/containers to a devDependency and let packem inline its source into dist, so the fixes we carry as a pnpm patch actually ship to consumers. A published runtime dep would resolve to the pristine, still-buggy 0.3.7 on a consumer machine; bundling the patched source bakes the fixes into what we publish. The patch backports two upstream PRs: - cloudflare/containers#191: alarm-scheduler spinloop under concurrent callers (alarm fires sub-second, saturates the DO event loop, cancels WebSocket upgrades) — re-arm a single storage alarm, idempotent scheduleNextAlarm. - cloudflare/containers#230: NOT_LISTENING_ERROR did not match the wrangler-dev message, hanging the local readiness loop. packem externalizes only the cloudflare:workers built-in; everything else inlines. @lunora/container/do is now self-contained (consumers no longer need @cloudflare/containers installed) and the package has zero runtime dependencies. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GxJinV1B4eyMBJnXEEDSfS
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
isNotListeningErrorhelper uses.toLowerCase().includes(matchingString)to detect the error. In production the runtime returns:In local dev (
wrangler dev) the runtime returns:The current constant
'the container is not listening'is not a substring of the local-dev variant (which omits the leading "the"), soisNotListeningErrornever returns true. The readiness loop inwaitForPort/startAndWaitForPortsretries indefinitely and the Durable Object blocks forever.Fix
Shorten the constant from
'the container is not listening'to'container is not listening'. This is a substring of both variants, so the.includes()check works in both environments.Environment
Not sure whether the Docker runtime (OrbStack vs Docker Desktop) matters for this particular issue. Mentioning it in case it is relevant.