`@astrojs/cloudflare`: cacheCloudflare() overrides an explicit `cache.enabled: false` in wrangler config

[skezo]

Astro Info

Astro                    v7.0.9
Vite                     v8.1.4
Node                     v22.23.1
System                   Linux (x64)
Package Manager          pnpm
Output                   server
Adapter                  @astrojs/cloudflare (v14.1.3)
Integrations             none

Describe the Bug

When a Cloudflare cache provider is configured (cache: { provider: cacheCloudflare() }), the adapter force-enables the Workers Cache in the emitted config even when the project's wrangler.jsonc explicitly sets "cache": { "enabled": false }. The built dist/server/wrangler.json comes out with "cache": { "enabled": true }, so the opt-out is silently rewritten.

The check at packages/integrations/cloudflare/src/wrangler.ts#L73 is

cache: needsWorkerCache && !config.cache?.enabled ? { enabled: true } : undefined,

and !config.cache?.enabled treats "unset" and "explicitly false" the same.

For context on why someone would set enabled: false while still using the provider: Workers Cache supports per-entrypoint enablement, e.g. "exports": { "Render": { "type": "worker", "cache": { "enabled": true } } } with the default export left uncached. That shape is useful for an uncached gateway that derives cache-key dimensions (host, region) into ctx.props and loops back into a cached named entrypoint via ctx.exports, which seems to be the documented way to add key dimensions the platform does not provide. The exports block passes through the customizer untouched; only the top-level enabled: false gets overridden. The workaround for now is post-processing dist/server/wrangler.json between build and deploy.

What's the expected result?

An explicit "cache": { "enabled": false } in the user's wrangler config survives the build. Checking for config.cache?.enabled === undefined rather than falsiness would keep the current auto-enable default for configs that do not mention cache at all, while respecting an explicit opt-out.

Link to Minimal Reproducible Example

https://github.com/skezo/astro-cf-repro/tree/cache-enabled-clobber

Participation

• I am willing to submit a pull request for this issue.

[astrobot-houston]

• Reproduced: Yes
• Exploration: Yes — View branch
• Unit Test: Yes — packages/integrations/cloudflare/test/wrangler.test.ts
• Priority: P3: minor bug. The bug only affects users who explicitly set cache: { enabled: false } in their wrangler config while using cacheCloudflare() — a niche but valid per-entrypoint caching pattern. A workaround exists (post-processing dist/server/wrangler.json).

The root cause is in packages/integrations/cloudflare/src/wrangler.ts line 73. The condition !config.cache?.enabled uses a falsy check, which treats both undefined (cache not configured) and false (cache explicitly disabled) identically. When needsWorkerCache is true and the user sets cache: { enabled: false }, the customizer overwrites it to { enabled: true }, silently ignoring the user's explicit opt-out.

I found a potential fix for this issue. The fix changes the falsy check (!config.cache?.enabled) to a strict undefined check (config.cache?.enabled === undefined), so auto-enabling only kicks in when the user hasn't configured cache at all. An explicit false is now preserved. Four new unit tests cover the cache-related scenarios.

Try this fix

You can test this fix right now without waiting for a release:

pnpm add https://pkg.pr.new/@astrojs/cloudflare@474b589

If this fixes your issue, please leave a comment letting us know (e.g. "confirmed, this fixes it"). We'll then open a pull request to get this merged.

Full Triage Report

Reproduction

Confirmed the bug using a unit-level test against cloudflareConfigCustomizer:

const customizer = cloudflareConfigCustomizer({ needsWorkerCache: true });
const result = customizer({ cache: { enabled: false } });
// result.cache is { enabled: true } — BUG: should be undefined (preserve user's setting)

Diagnosis

File: packages/integrations/cloudflare/src/wrangler.ts, line 73

cache: needsWorkerCache && !config.cache?.enabled ? { enabled: true } : undefined,

The !config.cache?.enabled expression evaluates to true for both:

• config.cache is undefined → !undefined → true (correct: should auto-enable)
• config.cache.enabled is false → !false → true (incorrect: should respect opt-out)

This is inconsistent with other fields in the same function (e.g. main, compatibility_date, assets) which use nullish coalescing or explicit !== undefined checks.

Introduced in commit 9a53f77d35 (PR #16335, "feat: add CDN cache providers").

Fix

Changed the condition to use a strict undefined check:

cache: needsWorkerCache && config.cache?.enabled === undefined ? { enabled: true } : undefined,

This preserves the auto-enable behavior when cache is not configured, while respecting an explicit enabled: false.

Tests Added

Four new tests in packages/integrations/cloudflare/test/wrangler.test.ts under a worker cache describe block:

1. Auto-enables cache when needsWorkerCache is true and cache is not configured
2. Does not enable cache when needsWorkerCache is false
3. Does not override when cache is already enabled: true
4. Does not override explicit cache.enabled: false (regression test for @astrojs/cloudflare: cacheCloudflare() overrides an explicit cache.enabled: false in wrangler config #17375)

All 29 tests pass.

This report was made by an LLM. The analysis may be wrong, and the potential fix might not work, but is intended as a starting point for exploring the issue.

[skezo]

Confirmed, this fixes it. Tested the preview build (pkg.pr.new/@astrojs/cloudflare474b589) against the repro: with "cache": { "enabled": false } in wrangler.jsonc the emitted dist/server/wrangler.json now keeps {"enabled": false}, and with no cache key at all it still auto-enables to {"enabled": true}. Both behaviors look right from our side. Thanks for the quick triage.

[astrobot-houston]

The fix has been verified! A pull request has been created: #17376