bug(0.18): catch-all routes silently return null from getEmDashEntry - 'route cache overwritten' warning

[Vallhalen]

Summary

After upgrading from 0.16.1 → 0.18.0, all CMS-driven pages served via catch-all routes (src/pages/[slug].astro, src/pages/en/[slug].astro) silently return null from getEmDashEntry, causing them to fall through to a 404 / redirect. Pages with dedicated .astro files (e.g. regulamin.astro) continue to work fine.

Reproduced twice with deploy → rollback → re-deploy cycle (versions f3ce6777 and 5d84583b). Same affected pages, same warning in wrangler tail. Same site, same content - only the EmDash version differs.

Repro

1. Site uses two catch-all routes that resolve CMS entries via getEmDashEntry:

• src/pages/[slug].astro - Polish (default locale)
• src/pages/en/[slug].astro - English (locale en)

2. Upgrade emdash, @emdash-cms/cloudflare, @emdash-cms/admin from 0.16.1 to 0.18.0 (cloudflare adapter, D1).
3. npm run build && wrangler deploy.
4. Hit any CMS-driven page (e.g. /konsultacje, /en/terms).

Result: getEmDashEntry("pages", "konsultacje") returns { entry: null }. Rendered routes fall through to Astro.redirect("/404") (302) or Astro.rewrite("/404") (404).

Warning observed via wrangler tail --format pretty

Every request to an affected page logs:

[WARN] Internal Warning: route cache overwritten. (/[slug]_src/pages/[slug].astro)
[WARN] Internal Warning: route cache overwritten. (/en/[slug]_src/pages/en/[slug].astro)
[WARN] [cache] `cache.set()` was called but caching is not enabled.
 Configure a cache provider in your Astro config under `experimental.cache` to enable caching.

The (.../path/file.astro) suffix is unusual - the leading / and missing separator before _src suggest some kind of internal cache-key derivation that's clobbering itself. Both PL and EN catch-alls produce the warning, and both are affected.

Working vs broken in production

Site: chcedointernetu.pl (long-migrated EmDash instance, 0.5 → … → 0.16.1 chain).

URL	Type	0.16.1	0.18.0
/ (home)	hardcoded index.astro	200	200 ✅
/regulamin, /polityka-prywatnosci, /polityka-cookies, /dostepnosc	hardcoded .astro files	200	200 ✅
/blog, /portfolio, /uslugi	listing pages	200	200 ✅
/konsultacje	CMS via [slug].astro	200	302 → /404 ❌
/deklaracja-etycznego-wykorzystania-ai	CMS via [slug].astro	200	302 → /404 ❌
/en/consultations, /en/terms, /en/privacy-policy, /en/cookie-policy, /en/ai-ethics, /en/accessibility	CMS via en/[slug].astro	200	404 ❌

So: hardcoded routes - fine. Catch-alls calling getEmDashEntry - broken.

The same SQL row exists in D1 and is returned correctly by both the REST API (/_emdash/api/content/pages/konsultacje?locale=pl) and raw wrangler d1 execute - so it's not a data issue. Something in the catch-all getEmDashEntry path is hitting the broken code path post-0.17.

Background - same regression on 0.17

We hit a narrower version of this on 0.17.2 back on 2026-06-07 - at that point only 4 pages were affected, all CMS-driven, all on these same catch-all routes. Hardcoded .astro pages worked then too.

After upgrading to 0.18.0 the regression expanded: 9 pages affected instead of 4 (every CMS page hit via the catch-alls, including all 6 EN translations refreshed yesterday via MCP). Nothing in our setup changed between the two attempts other than the EmDash version.

The fresh-install repro attempt we did on 0.17.2 did not trigger the bug - only this long-migrated production instance does. So the trigger likely sits at the intersection of (catch-all getEmDashEntry + accumulated migration state). The "route cache overwritten" warning landing on exactly these routes feels like the closest signal we've had yet.

Environment

• emdash@0.18.0, @emdash-cms/cloudflare@0.18.0, @emdash-cms/admin@0.18.0
• astro@6.4.x on Node 22, deployed to Cloudflare Workers
• D1 binding (session: "auto"), R2 binding
• Custom plugins: formsPlugin, backupPlugin, cookiesPlugin, inactiveTabTitle
• mcp: true
• Site has been continuously migrated since EmDash 0.5

What I'd love to know

1. Is the route cache overwritten warning a known signal from 0.18's startup-concurrency changes (perf(core): emit stream-end metrics to expose post-header query cost #1407 / perf(core): parallelize cold-boot init phases and batch exclusive-hook reads #1408) or query-batching changes (perf(core): fix query waterfalls — getTerm parallelism, hydrated terms reuse, menu pattern caching #1409)?
2. Is there a way to disable the internal cache that triggers this - experimental.cache config hint suggests there might be a knob?
3. Does the catch-all getEmDashEntry path go through a different code branch in 0.18 that I should be aware of?

Happy to provide more diagnostics - wrangler tail JSON, schema dumps, anything. Rolled back to 0.16.1 again in the meantime.

Tagging earlier related thread: was about to revisit the 0.17 ticket but the 0.18 expansion seems like the cleaner repro to start from.

[Vallhalen]

Update: tested 0.19.0 on the same long-migrated production instance (same setup, same data) - regression unchanged.

• All 9 CMS pages still 404 / 302 via the catch-all routes.
• wrangler tail still emits the same warning on every request:

  [WARN] Internal Warning: route cache overwritten. (/[slug]_src/pages/[slug].astro)
  [WARN] Internal Warning: route cache overwritten. (/en/[slug]_src/pages/en/[slug].astro)
  

• Hardcoded .astro pages still serve 200 correctly.
• Migration to the new @emdash-cms/cloudflare/worker entry + Cron Trigger from fix(scheduling): drive scheduled publishing from a real heartbeat #1312 applied cleanly, no other build / deploy issues.

So the 0.19 patches (most relevantly #1445 for getEmDashEntry term hydration, and #1307 for locale forwarding in write routes) do not address this case. The "route cache overwritten" signal seems independent of those fixes.

Rolled back to 0.16.1 again. Still happy to provide whatever diagnostics would help track it down.

[Vallhalen]

Update: 0.21.0 fixes this on our long-migrated instance.

All 9 previously failing CMS routes now return 200 with the correct rendered content. wrangler tail no longer emits the route cache overwritten warning on any of them.

Strong suspicion that the actual fix shipped as part of the wedged-isolate cache cleanups in:

• fix(core): prevent isolate-poisoning hangs from cached in-flight promises #1489 (0.20) - site settings / search-index health caches
• fix: close remaining isolate-poisoning hangs after #1489 #1530 (0.21) - byline custom-field definitions / resolved site secrets caches

Both follow the same pattern as our symptom (per-isolate cache holding a never-settling promise from a cancelled request and wedging subsequent requests).

Closing as fixed. Thanks!

[Vallhalen]

Reopening — 0.21.0 introduced a new regression that affects the pages collection specifically.

After upgrading to 0.21.0:

• All 9 originally-failing CMS pages return 200 (the route cache overwritten warning is gone, confirming fix(core): prevent isolate-poisoning hangs from cached in-flight promises #1489/fix: close remaining isolate-poisoning hangs after #1489 #1530 fixed the wedged-isolate-cache symptom we observed).
• BUT getEmDashEntry("pages", "home") and getEmDashEntry("pages", "konsultacje") now return { entry: null, error: {} } even though the rows exist in ec_pages (verified via direct D1 query).
• getEmDashEntry("services", slug) and getEmDashCollection(...) work correctly.

Detail:

• Verified via console.log in worker tail: same call from same page; direct db.selectFrom("ec_pages").where("slug","=","home").where("locale","=","pl").execute() returns the row with all 98 columns populated, but getEmDashEntry returns null.
• Tried: with locale "pl", by full ULID, without locale — all three return entry: null with empty error.
• The ec_pages table has 98 columns (heavy flat-field collection); ec_services has fewer (~30) and works fine, so the issue may be column-count or specific-column related, not generic to all entry lookups.
• Confirmed not data-state: PITR'd D1 back, reinstalled 0.16.1, redeployed — homepage immediately renders correctly with the same data.

Possibly related to the migration into per-collection ec_* tables that came in 0.20. We're rolled back to 0.16.1 again. Happy to share more debugging info / repro instance if useful.

[Vallhalen]

Update: 0.22.0 — same regression as 0.21, rolled back again.

Tested 0.22.0 on the same long-migrated production instance:

• All 9 originally-failing CMS pages return 200 (the route cache overwritten fix from 0.20/0.21 still holds).
• BUT homepage from getEmDashEntry("pages", "home") still returns null - homepage renders with only 4 h2 sections (banner cards) instead of 11. The pages collection-specific regression introduced in 0.20 is NOT fixed by fix(core): prevent isolate-wide hang from a stalled session.get on Workers (#1274) #1538.

Noticed #1538 (Cloudflare session-store isolate poisoning) follows the same wedged-promise pattern as #1489/#1530 - hoped it might cover our case too, but no. Looks like the pages collection issue is a separate bug rooted in the per-collection ec_* tables migration (0.20), not the isolate-cache series.

PITR'd D1 back to bookmark 000054e1-..., reinstalled 0.16.1, redeployed - homepage works again immediately with the same data.

Happy to share a repro D1 dump or remote access if useful. Holding at 0.16.1 again.

[Vallhalen]

ROOT CAUSE FOUND 🎯

Turns out it's not a regression in EmDash code - it's a D1 result set column limit that our specific schema crossed when 0.20 introduced per-collection ec_* tables.

The loader's loadEntry query does:

SELECT c.*, _emdash_seo_title, _emdash_seo_description,
            _emdash_seo_image, _emdash_seo_canonical, _emdash_seo_no_index
FROM ec_<collection> AS c
LEFT JOIN _emdash_seo AS s ON s.collection = ? AND s.content_id = c.id
WHERE ...

Our ec_pages table has 98 flat columns (legacy schema with sec_dlaczego_*, sec_about_*, sec_features_*, sec_faq_*, plus repeated flat groups like dlaczego_1_title/desc/image × 3, whyus_1_* × 3, stat_N_value/label × 3, etc.).

98 (table cols) + 5 (SEO alias cols) = 103 columns in the result set → D1 throws:

D1_ERROR: too many columns in result set: SQLITE_ERROR

The error gets swallowed by the loader's try/catch which wraps it as { error: new Error("Failed to load entry: ...") }. In getEmDashEntry it's surfaced as null + error. But JSON.stringify(error) returns "{}" for Error objects (message is non-enumerable), which is why my earlier debug logs showed empty errors and made this look like a silent null return.

How I diagnosed it: added console.log(error.message) instead of JSON.stringify(error) and the real message appeared immediately:

[DEBUG home 0.22] entry null? true error? Failed to load entry: D1_ERROR: too many columns in result set: SQLITE_ERROR

Fix on our side (works):
Dropped 8 unused columns from ec_pages (98 → 90, total result set 95, safely under D1's ~100 limit). Homepage now renders correctly on 0.22 with all content.

Suggested fix on EmDash side (much wider impact):
The LEFT JOIN _emdash_seo adds 5 columns to every c.* query. For collections with wide schemas this pushes them over D1's limit. Two options:

1. Fetch SEO with a separate query when the table is wide (defensive)
2. Select only the columns the loader actually needs (status, slug, locale, published_at, scheduled_at, deleted_at, etc.) plus the JSON data and the SEO aliases — instead of c.*. This would be backward compatible since mapRowToData only reads known keys anyway.

Either approach would protect long-lived flat-schema sites from this failure mode. Wide flat schemas are common when migrating from WordPress/ACF or other CMSes where every section is a top-level field. Happy to PR if helpful.

Closing this on our end since we've resolved it via column reduction, but leaving the diagnosis here for anyone else who hits it on a long-migrated instance with a wide collection schema.