Skip to content

fix: Add /__void/ready handler to framework-mode wrapper - #203

Merged
Brooooooklyn merged 1 commit into
mainfrom
fix/framework-mode-ready-probe
May 15, 2026
Merged

Brooooooklyn merged 1 commit into
mainfrom
fix/framework-mode-ready-probe

Conversation

@Brooooooklyn

@Brooooooklyn Brooooooklyn commented May 15, 2026 •

Copy link
Copy Markdown
Member

Summary

  • Framework-mode worker wrapper (used for SvelteKit/Astro/Nuxt/etc. when the project has migrations, crons, or queues) did not handle GET /__void/ready, so the request fell through to the user's framework handler. For SvelteKit on Cloudflare, that path is routed to env.ASSETS, which returns the well-known stub "Assets have not yet been deployed to this script." during the WfP asset-propagation window.
  • Void's deploy-time readiness probe polls /__void/ready on the freshly-uploaded worker before dispatching migrations and expects a JSON { ready: true } response. The asset stub fails every retry, so framework deploys with at least one pending migration time out the probe (~63s) and abort with "worker readiness probe failed: new worker not reachable after retries". Meanwhile void db migrate --remote succeeds because it bypasses the worker entirely.
  • Mirror the existing handler from the void-mode compile path (router/compile.ts) into the framework-mode wrapper: respond to GET /__void/ready with Response.json({ ready: true }) before delegating to the user's original fetch.

Test plan

  • New unit test in wrapper.test.ts asserts the wrapper emits the /__void/ready branch returning { ready: true }, ordered before the fall-through to original.fetch.
  • All 12 wrapper.test.ts tests pass.
  • Full void unit suite (2065 tests) green; typecheck clean.
  • Manually verify a framework-mode deploy (e.g. SvelteKit) with a pending migration no longer times out the readiness probe.

🤖 Generated with Claude Code


Note

Low Risk
Low risk: adds a small internal route in the generated wrapper plus a unit test; behavior only changes for GET /__void/ready when wrapper interception is enabled.

Overview
Fixes framework-mode wrapper generation to intercept GET /__void/ready and return Response.json({ ready: true }) before delegating to original.fetch, preventing readiness probes from falling through to framework asset handlers during deploy propagation.

Adds a unit test asserting the /__void/ready branch is emitted in the generated wrapper and appears before the original.fetch fall-through.

Reviewed by Cursor Bugbot for commit 25f4229. Bugbot is set up for automated code reviews on this repo. Configure here.

@netlify

netlify Bot commented May 15, 2026 •

Copy link
Copy Markdown

✅ Deploy Preview for staging-void-cloud ready!

Name Link
🔨 Latest commit 25f4229
🔍 Latest deploy log https://app.netlify.com/projects/staging-void-cloud/deploys/6a06dd2c34b3c100084b31a7
😎 Deploy Preview https://deploy-preview-203--staging-void-cloud.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
🤖 Make changes Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

@Brooooooklyn
Brooooooklyn merged commit b276721 into main May 15, 2026
10 checks passed
@Brooooooklyn
Brooooooklyn deleted the fix/framework-mode-ready-probe branch May 15, 2026 09:43
cpojer pushed a commit that referenced this pull request Sep 11, 2026
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant