[miniflare] Use polling watcher for dev registry on Windows#13659
Conversation
On Windows, chokidar's default `fs.watch` backend (`ReadDirectoryChangesW`) frequently drops or delays create events for files added shortly after the watcher attaches — especially under CI virtualization. The in-process `getPlatformProxy` scenario is uniquely exposed to this because it attaches its watcher before the partner Vite/Wrangler subprocess writes its registry file, so a missed event means the external-service binding never resolves until the 30-second heartbeat. Switch the dev registry's chokidar watcher to polling mode on Windows so cross-process worker registrations are observed reliably, and bump the fixture test's `waitForTimeout` to 20s as defense-in-depth on slow Windows CI runners. Fixes the flaky `fixtures/dev-registry/tests/dev-registry.test.ts:959` assertion.
🦋 Changeset detectedLatest commit: 7880d61 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Codeowners approval required for this PR:
Show detailed file reviewers |
Changeset ReviewFile Reviewed:
|
| Criteria | Status | Notes |
|---|---|---|
| Version Type | ✅ | patch for miniflare is appropriate - this is a reliability/bug fix |
| Changelog Quality | ✅ | Excellent description with detailed explanation of the Windows fs.watch issue and the polling solution |
| Markdown Headers | ✅ | No h1/h2/h3 headers found |
| Analytics | ✅ | No analytics collection mentioned |
| Dependabot | ✅ | Not a dependabot changeset |
| Experimental Features | ✅ | Not an experimental feature |
Details
The changeset provides:
- Clear, imperative title describing the fix
- Comprehensive explanation of the root cause (chokidar default settings on Windows using
fs.watch/ReadDirectoryChangesWwhich drops/delayed events) - Description of the solution (polling mode on Windows with 100ms interval)
- Note that non-Windows platforms continue using native filesystem events
The description is technical but accessible, explaining both the problem and solution effectively for changelog readers.
|
The changes are straightforward and well-motivated. Let me verify there are no other concerns:
Everything here is clean — the root cause analysis is sound, the fix is minimal and targeted, and there are no logic bugs, security issues, or backward compatibility concerns. LGTM |
create-cloudflare
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-editor-shared
wrangler
commit: |
workers-devprod
left a comment
There was a problem hiding this comment.
Codeowners reviews satisfied
Fixes the flaky
fixtures/dev-registry/tests/dev-registry.test.ts:959assertion that has been failing intermittently on Windows CI (e.g. this run).Root cause
The filesystem-based dev registry uses
chokidarwith default settings to watch~/.wrangler/registry/. On Windows, chokidar defaults tofs.watch(backed byReadDirectoryChangesW), which is known to drop or delay create events for files added shortly after the watcher attaches — especially under CI virtualization.The
getPlatformProxy → wrangler/vite devtest suite is uniquely exposed to this because, unlike the other suites in the file, it attaches its watcher in-process first, then spawns a subprocess that writes the peer worker's registry file. Every other suite spawns both processes as subprocesses, so by the time the second process's watcher attaches, the file already exists on disk and chokidar's initial directory scan reliably picks it up.When the
addevent is dropped, the platform proxy never learns of the new worker until the 30s heartbeat touchesmtime— far beyond the test's 10swaitForTimeout. All subsequentenv.WORKER_ENTRYPOINT_WITH_ASSETS.fetch()calls return the "not found" 503 and the test times out.Fix
{ usePolling: process.platform === "win32", interval: 100 }to the chokidar watcher inpackages/miniflare/src/shared/dev-registry.ts. Polling sidesteps the dropped-event problem; the registry directory is tiny so the cost is negligible. Non-Windows platforms continue to use the efficient native backend. There's existing precedent for this pattern inpackages/vite-plugin-cloudflare/playground/vitest-setup.ts.waitForTimeoutfrom 10s to 20s as defense-in-depth on slow Windows CI runners.Verification
pnpm --filter @fixture/dev-registry test:ci→ 23/23 passed locally on macOS (polling is disabled there, so this confirms no regression on the native-backend path).A picture of a cute animal (not mandatory, but encouraged)