Session KV lookup hangs indefinitely, blocking entire page response for logged-in users

[marcusbellamyshaw-cell]

Product: EmDash CMS
Version: 0.15.0 (first observed in 0.14.0, confirmed still present in 0.15.0)
Adapter: @astrojs/cloudflare (Cloudflare Workers + KV)
Date: 2026-05-29

---

Summary

When a user has an active EmDash admin session cookie, page loads occasionally hang indefinitely — the browser tab spinner spins forever and no HTML is delivered. The issue is intermittent and clears on its own after some time. It never occurs in private/incognito windows (no cookie).

The issue affects any browser (confirmed on Chrome desktop and Chrome iOS).

---

Steps to reproduce

1. Log into the EmDash admin panel in a browser (establishes a session cookie)
2. Navigate to any public-facing page on the site (e.g. the homepage)
3. Observe: the browser tab spinner runs indefinitely — no HTML is received, the page never renders
4. Open the same URL in a private/incognito window (no session cookie) → page loads immediately and correctly
5. Once the hang starts, all pages on the site hang for that browser — retrying does not help. The issue persists until the session cookie is cleared (e.g. via browser cache wipe). It can occur after hours of normal use with no obvious trigger.

---

Expected behaviour

If the session KV lookup is slow or unavailable, EmDash's auth middleware should either:

• Time out after a reasonable threshold (e.g. 3–5 seconds) and continue the request with locals.user = null (degrade gracefully — treat the user as unauthenticated for this request), or
• Return a partial/fallback response rather than holding the response stream open indefinitely

The public page should always load. Admin toolbar features can safely be absent when the session cannot be confirmed quickly.

---

Actual behaviour

The response stream is never completed. The Worker holds the connection open indefinitely (until Cloudflare's 30-second subrequest/CPU limit forces a termination). The user sees an empty browser tab with a spinning loading indicator.

---

Secondary Error: sandboxed plugin fires on every request

A separate error log reveals a second issue firing on every page load across the entire site:

EmDash: Sandboxed plugin atproto page:metadata error: Error: Storage collection not declared: records

This occurs on every GET request to any post or page, continuously throughout the day. The outcome: ok means it is non-fatal and pages load successfully. However:

1. The atproto marketplace plugin is invoking a Worker-to-Worker call (via the LOADER sandboxed plugin binding) on every single page request
2. The plugin is misconfigured — it requires a storage collection named records which has not been declared
3. Normally this fails fast and is swallowed, but if the sandboxed LOADER Worker is under load, this call could stall instead of failing — which may be a contributing factor to the intermittent hangs

Immediate fix: either configure the atproto plugin with the required records storage collection, or uninstall it from the EmDash marketplace if it is not in use. Eliminating this unnecessary Worker-to-Worker call on every request reduces overhead and removes a potential hang vector.

---

Log Evidence

Cloudflare Workers observability traces confirm two hang windows, both exclusively affecting a single device: iPhone running Chrome (CriOS/149, Houston TX). All other devices — iPhone Safari, Windows Chrome, bots, uptime monitors — load normally throughout both windows.

Window 1: ~10:08–10:10pm CDT (03:08–03:10 UTC)

Time (UTC)	URL	Wall time	CPU time	Outcome	UA
03:08:49	GET /	60,550 ms	88 ms	canceled	iPhone Chrome
03:09:16	GET /	4,100 ms	6 ms	canceled	iPhone Chrome
03:09:21	GET /_emdash/admin	60,149 ms	67 ms	canceled	iPhone Chrome
03:09:54	GET /	36,350 ms	43 ms	canceled	iPhone Chrome
03:10:28	GET /	1,508 ms	88 ms	✓ ok	iPhone Safari
03:10:40	GET /	1,535 ms	116 ms	✓ ok	iPhone Chrome

The iPhone Chrome load at 03:10:40 succeeded immediately after the user cleared their browser cache (removing the session cookie).

Window 2: ~11:05–11:13pm CDT (04:05–04:13 UTC)

Time (UTC)	URL	Wall time	CPU time	Outcome	UA
04:05:01	GET /	30,000 ms	36 ms	canceled	iPhone Chrome
04:05:34	GET /	60,050 ms	48 ms	canceled	iPhone Chrome
04:08:32	GET /_emdash/admin/logout	5,800 ms	5 ms	canceled	iPhone Chrome
04:08:38	GET /_emdash/admin/logout	60,850 ms	56 ms	canceled	iPhone Chrome
04:10:11	GET /_emdash/admin/logout	50,600 ms	48 ms	canceled	iPhone Chrome
04:11:02	GET /_emdash/admin/logout	170,400 ms	158 ms	canceled	iPhone Chrome
04:11:08	GET /	60,100 ms	54 ms	canceled	iPhone Chrome
04:13:34	GET /	17,849 ms	16 ms	canceled	iPhone Chrome

Critical pattern across all hung requests: CPU time is 5–158 ms; wall time is 4,000–170,400 ms. The Worker executes a tiny amount of code then waits on I/O indefinitely. This is not CPU exhaustion — it is a blocking I/O call with no timeout.

All hung requests have no child spans in the trace data — no D1 queries, no KV reads, no R2 operations were recorded. This is consistent with either (a) the Worker stalling before reaching any binding, or (b) a binding call (e.g. KV session read) hanging mid-execution — in which case its span would never be emitted. A normal successful GET / completes in ~1.2 seconds with ~28 child spans.

Diagnosis

The symptom — browser tab spinner, not an in-page spinner — indicates the HTTP response itself never starts arriving, not a client-side JavaScript failure. Because the issue is:

• Consistent when a session cookie is present
• Never occurs without a session cookie (private window, other browsers without a session, external uptime monitors)
• Affects any browser (confirmed on Chrome desktop and Chrome iOS)
• Intermittent (sometimes fast, sometimes hangs)

The trace evidence rules out KV latency or slow D1 queries as the cause — the Worker stalls before any binding is accessed. This points to something in EmDash's request initialization path (module-level code, middleware setup, or sandboxed plugin bootstrap) that deadlocks or blocks indefinitely for certain requests, likely triggered by the presence of a session cookie.

---

Environment

• Runtime: Cloudflare Workers (zone-routed, not workers.dev)
• Session storage: Cloudflare KV (SESSION binding)
• Database: Cloudflare D1
• Astro output: server (full SSR, no static generation)

---

Impact

• Affects only users with active admin sessions — public visitors are unaffected
• During a hang window, the admin cannot load any page on the site in any browser while logged in, without switching to private mode or logging out
• Workaround: clear browser cookies/cache for the site, which removes the session cookie and restores normal loading
• No data loss; the site is fully functional for visitors without a session cookie

---

Suggested fix

Since the hang occurs before any binding is accessed, the fix likely needs to be in the request initialization path rather than in a specific binding call. A global request timeout guard would prevent indefinite hangs regardless of where in initialization the stall occurs:

// Pseudocode — exact implementation depends on EmDash internals
const INIT_TIMEOUT_MS = 5_000;

async function handleRequest(request: Request, env: Env, ctx: ExecutionContext) {
  const timeout = new Promise<Response>((resolve) =>
    setTimeout(() => resolve(new Response("Service unavailable", { status: 503 })), INIT_TIMEOUT_MS)
  );
  return Promise.race([processRequest(request, env, ctx), timeout]);
}

Alternatively, if the stall is in session validation specifically, a timeout with graceful fallback to unauthenticated state would prevent the hang while keeping the page functional for the visitor.

[emdashbot]

The investigation bot declined to reproduce this issue.

Reason: Skipping local reproduction. This bug is not reproducible in the demo environment for the following reasons:

1. Production-only environment dependencies. The issue manifests on a deployed Cloudflare Worker with @astrojs/cloudflare adapter, KV SESSION binding, D1, and zone routing. The demos run on Node + better-sqlite3 (or wrangler dev at best) and use SQLite-backed sessions — they do not use the Cloudflare KV binding that the reporter implicates as the suspected stall site.

2. Intermittent + device-specific. The Cloudflare trace evidence shows the hang exclusively affects one device (iPhone Chrome / CriOS 149 from Houston TX) within narrow time windows, while all other UAs hitting the same Worker simultaneously succeed in ~1.2s. The reporter explicitly calls it intermittent ("can occur after hours of normal use with no obvious trigger"). There is no deterministic trigger to invoke locally.

3. No child spans = pre-binding stall. Cloudflare observability shows hung requests have CPU 5–158ms but wall time 4–170s with zero child spans emitted. The Worker stalls before any D1/KV/R2 call is recorded. Replicating this requires the actual Workers runtime + bindings; wrangler dev's local emulation does not exhibit the same scheduling/I/O behaviour as the edge.

4. Hard prohibitions matter here. The skill restricts the bot to localhost:4321 against the demo. There is no way to drive a deployed zone-routed Worker from this sandbox, and impersonating CriOS UA against a local demo would not exercise the suspect code path (KV session lookup) because the demo has no KV binding.

Per the skill's "When to skip" guidance, this matches "The bug only manifests on a deployed Worker — caching headers from the CF edge, geographic routing, image transformation through the production R2 binding." It is the same class of failure — production-Workers-only, intermittent, and tied to a specific binding (KV SESSION) not present in the demo.

The issue body is already extremely detailed and contains the diagnosis pointers a maintainer needs: the request init path before any binding access, the session-cookie-presence correlation, the secondary atproto sandboxed-plugin error firing on every request as a possible contributing hang vector. The diagnose stage should focus on auditing the middleware chain (runtime init → setup check → auth → request context ALS) and the sandboxed plugin loader for any unawaited promise / unbounded await / module-init deadlock — none of which require a live reproduction to inspect.

Recommend the orchestrator route this directly to the diagnose stage with reproduced: false, skipped: true.

_{Run: https://github.com/emdash-cms/emdash/actions/runs/26781334757}

[marcusbellamyshaw-cell]

Update — 2026-06-01: hang confirmed on anonymous (no-cookie) requests

Today's incident provided new data that revises the original diagnosis.

New evidence

Cloudflare Workers observability captured a hung invocation at ~22:11 UTC today:

Field	Value
URL	GET /
CPU time	8 ms
Wall time	944,510 ms (944 seconds)
Outcome	canceled (Cloudflare terminated the Worker)
Session cookie present	No (anonymous request)
Plugin loading logs	None — stall happened before EmDash logged any plugin initialization

Key revision: the original report assumed the hang was tied to the presence of a session cookie. This invocation had no session cookie. The stall occurred before any plugin was loaded, suggesting the issue is in EmDash's core request initialization path — not in session validation specifically.

The concurrent admin session in the same browser may have been a red herring, or at minimum the hang is not limited to session-bearing requests. Anonymous requests can also stall before any binding call is recorded.

Timeline

• ~22:11 UTC: GET / hangs (anonymous). Cloudflare holds the connection for 944 seconds, then cancels the Worker invocation.
• 22:22 UTC: External synthetic monitor (Checkly) hits the site, gets a slow response, times out at its own 3-second Playwright threshold — confirms the site was degraded at that point.
• ~22:17 UTC: Site returns to normal (concurrent requests complete in 235–450 ms).

Revised diagnosis

The stall is occurring in EmDash's initialization before plugins are loaded and before any spans are emitted. This affects both authenticated and anonymous requests. The no-child-spans pattern in traces is now confirmed to be a pre-initialization stall, not a session-specific one.

Workaround deployed on our end

We've wrapped the Worker entrypoint in a Promise.race against a 10-second deadline that covers all requests (not just session-bearing ones). On timeout, session requests get cookies cleared + a 302 redirect; anonymous requests get a 503 with Retry-After: 5. This prevents the 900-second browser hang but does not fix the underlying EmDash initialization stall.

[marcusbellamyshaw-cell]

Correction to previous comment: The claim that "the hang-guard was in place but didn't fire because the request was anonymous" may not be accurate. The 944-second wall time actually suggests the guard was not yet deployed to production when this hang occurred — a deployed 10-second timeout would have capped the duration at ~10 seconds, not 944. The guard went live today with the workaround deploy.

The core finding stands: a GET / hung before any plugin-loading logs were emitted, confirming the stall is in EmDash's pre-initialization path and is not exclusively triggered by the presence of a session cookie. But the cause of the guard not firing was most likely "it wasn't deployed yet," not "the anonymous request bypassed it."

Also noting: Cloudflare Workers observability logs do not expose request headers, so I cannot confirm with certainty whether the GET / had a session cookie or not. The stall pattern (pre-plugin, no spans) is the reliable evidence; the "anonymous" characterization is an inference.

[sam-fakhreddine]

Independent reproduction on a separate production site — and it looks broader than session-KV-only

We're hitting the same fingerprint on a different EmDash site (Astro + Cloudflare Pages + D1) and want to add hard data, since this is currently triage/skipped. The signature matches the original report — minimal CPU, multi-second-to-minute wall time, request blocked on I/O, intermittent.

Two differences that I think broaden the issue beyond the "session KV lookup" framing in the title:

1. We reproduce it on unauthenticated, no-cookie public requests (first-hit cold renders and crawler traffic), not just logged-in admin sessions. Either the session/KV path runs for anonymous requests too, or the blocking I/O isn't exclusively the session lookup.
2. Our server-timing attributes the stalled wall-time to the middleware + DB phase, not specifically a KV get — so this may be a more general pre-init/middleware I/O stall that the session KV lookup is one trigger of. (Sharing raw numbers below; happy to be corrected on the attribution.)

Environment

• emdash 0.17.2, @emdash-cms/cloudflare 0.17.2, @emdash-cms/auth-atproto 0.2.11
• astro 6.4.2, @astrojs/cloudflare 13.6.1
• Cloudflare Pages (Workers runtime), D1, KV, R2, nodejs_compat

What we measure (all on public, unauthenticated GETs)

Six cache-busted cold renders of the same page, back to back:

run	db.total	queries	render
1	3,505 ms	43	2,977 ms
2	2,418 ms	43	1,866 ms
3	1,380 ms	34	1,380 ms
4	16,165 ms	43	13,507 ms
5	866 ms	34	866 ms
6	23,640 ms	34	23,640 ms

It's strongly bimodal: the same route, same query set, is either healthy (~0.9–1.4 s) or catastrophic (16–24 s), nothing in between. A representative server-timing header from a slow one:

render;dur=8267, mw;dur=10092 (total middleware),
db.total;dur=10381, db.count;dur=43, db.last;dur=10092 (last query fired ~10s into the request),
rt.db;dur=644 (init+migrations), rt.hooks;dur=305, rt.plugins;dur=140

The init phases are small; the time is the request sitting blocked while almost no CPU is used — same I/O-block fingerprint as the original report (their CPU 5–158 ms vs wall 170 s).

This is not D1 query cost, and not a bad D1 instance:

• The exact same code and the exact same 43 queries run in ~33 ms TTFB locally (SQLite). 33 ms local vs up to ~23 s deployed is not query execution time.
• We had a concurrent degraded-D1 incident, so we cloned our data to a fresh, healthy D1 instance and repointed the app. Baseline D1 latency recovered — but the bimodal stalls persisted. So the stall is independent of the D1 instance; it lives in the EmDash request/pre-init path.

Client-visible impact, from a headless click-latency test (fresh browser context, no auth, deployed):

• cold click→navigation: 44.9 s, warm (prefetched): 44.6 s
• document TTFB pinned at ~15,044 ms — that's our own Worker-level render-deadline guard cutting the response at 15 s; without the guard the request hangs to the platform limit. In practice a first-time visitor or Googlebot just gets a spinner, then nothing.

Secondary error (same as the report): we run the same @emdash-cms/auth-atproto plugin and our middleware timing spends measurable time in the sandboxed-plugin/hook resolution phase. Happy to confirm whether we emit the identical Storage collection not declared: records message if that helps narrow it.

Why this matters / what we did: we shipped a 15 s render-deadline guard at the Worker layer (race the render against a deadline; serve stale-or-503 on timeout) as a tourniquet — but that only converts "hang forever" into "fail at 15 s," it isn't a fix. Because we can't ship a public launch where the first hit can stall 15–45 s, we've had to pivot our entire production launch away from EmDash SSR to fully static prerendering (getStaticPaths, content fetched at build time, no EmDash content layer in the request path). That removes the stall for us, but it means giving up runtime SSR on the public site specifically because of this bug.

This seems real and reproducible across at least two independent sites. We can provide full server-timing dumps across the bimodal distribution, the exact query set, and environment details on request. Would a minimal repro on Pages + D1 help reopen triage?

[sam-fakhreddine]

@ascorbic can the bot reassess?

[marcusbellamyshaw-cell]

Correction on device scope: the bot characterized this as affecting one device (iPhone Chrome / CriOS 149). That's not accurate — we've confirmed stalls on Safari and Chrome on desktop while logged in, and on a separate subscriber account on a different device. This is not UA- or device-specific.

Still hitting the same stall post all proposed fixes — nothing has resolved the root issue.

On the atproto angle: we previously ran @emdash-cms/auth-atproto and removed it as a troubleshooting step (reasonable suspect — DID resolution involves outbound HTTP calls that could stall before any spans are emitted). Stalls continued without it, so it's ruled out. Combined with sam's site reproducing with it installed, the cause is in core emdash's initialization path, not the atproto plugin.

Two independent sites, same version, different plugin configurations, same trace pattern — strong case for reopening triage.

[marcusbellamyshaw-cell]

External monitoring data (Checkly, last 30 days) — three checks on everybittexas.com:

Browser check — full page render (10-min interval, Playwright 210s timeout):

• Availability: 99.91%
• Response time avg: 8.1s, p95: 11.1s
• Failures: multiple "Test timeout of 210000ms exceeded" and "Timed out waiting 240s for test suite to run" — complete Worker non-response

Browser check — content rendering (5-min interval, Playwright 30s timeout):

• Failures include "Test timeout of 30000ms exceeded" and "Timed out 5000ms waiting for .toBeVisible" — page didn't render within 30s

URL check — /health endpoint (5-min interval, 5s max response threshold):

• Availability: 99.75%
• Response time p50: 103ms, p95: 1310ms
• Failures: "Max response time limit exceeded" occurring as recently as yesterday

The /health endpoint is a single new Response(JSON.stringify({ status: "ok" })) — no DB calls, no KV, no queries of any kind. If even that endpoint breaches 5 seconds, the stall is happening before any request handler code runs. This corroborates the no-child-spans trace pattern and points squarely at EmDash's Worker initialization/middleware layer, not content queries.