Repository navigation
fix(deploy): isolate Fastify startup and validate container readiness - #30
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🚀 Deploying Preview to Cloudflare 🚀Preview Deployments by commit
|
RlxChap2
changed the title
This branch was successfully deployed
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
1 participant
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.
Fastify initialization at module scope left the Worker awaiting Avvio plugin boot during Cloudflare startup validation. The previous entrypoint reproduces
Top-level await in module is unsettledlocally in workerd. This change runs the existing Fastify API in a Node.js container and keeps the Worker entrypoint limited to request routing through a native Durable Object.The Durable Object waits for
/readybefore forwarding the first request, shares initialization between concurrent requests, reapplies the inactivity timeout after re-instantiation, and checks readiness again after a container restart. Startup failures have a 30-second limit and a later request can retry. The Dockerfile uses its conventional filename and Wrangler loadssrc/worker.tsdirectly. Production pruning skips lifecycle scripts becauseprepareotherwise invokes Husky after its development dependency has been removed. CI reproduced that Docker build failure before this fix.Validation:
pnpm cloudflare:startupstarts the configured Worker in workerd successfully. It disables containers and checks Worker startup only.ffd85e5: Worker startup in workerd, production Docker image build,/healthHTTP response, ESLint, TypeScript and all 141 tests with coverage. Docker execution ran on the Linux runner.Workers Builds production settings:
A full Cloudflare deployment still requires the project's Containers configuration and credentials. Feature-branch container testing needs a separate staging Worker/environment with a full deploy.
wrangler versions uploadonly uploads Worker code and does not publish container images. See Cloudflare container deployment documentation.The Cloudflare Workers Builds check on the PR still reports failure and does not expose its detailed log through GitHub. Successful CI validates startup and the Docker image but does not prove a successful deployment to the production Cloudflare account.