Sign up
View stargazersSign up

Cloudflare Static Assets keys intermittently hang on staging Worker versions B/B2#196

openedJul 11, 2026byAAviddaram

Summary

Staging storefront versions B and B2 experienced a Cloudflare Workers Static Assets availability failure: selected hashed /_astro/*.js keys returned no headers and no bytes for minutes from the ULN egress, while neighboring assets returned immediately, another egress could fetch the same keys, and affected keys recovered independently over time.

This is intentionally separate from #194, which tracks stale SSR HTML/cache behavior. The evidence below points to a provider-side Static Assets serving/propagation incident rather than the application change in #194 / PR #195.

Versions and timing

Affected asset keys

The recursive import-graph probe found four affected B2 assets:

  • /_astro/product-image-carousel.gXm0dwbJ.js
  • /_astro/query.CXVTA0y2.js
  • /_astro/trpc.xrgk4jAl.js
  • /_astro/use-search-storefront.DKSy4TnM.js

A first scan found 40 of 43 recursive JavaScript assets returning HTTP 200. The affected requests timed out with curl exit 28, HTTP 000, and zero headers/bytes. GET, HEAD, and Range: bytes=0-99 reproduced the zero-header/zero-byte timeout for the carousel; its source map, direct imports, and adjacent PDP chunks returned 200.

Differential evidence

  • A separate fetch egress successfully retrieved the three keys still hanging from ULN (query, trpc, and use-search-storefront), proving the upload was not globally absent.
  • The exact trpc.xrgk4jAl.js pathname/content-address returned 200 from the restored A deployment on staging.amerikvitamin.mn but hung on the B2 preview from the same client.
  • Recovery was per key, not atomic: product-image-carousel recovered first with HTTP 200 / 3,953 bytes and cf-cache-status: HIT; use-search-storefront later recovered with HTTP 200 / 4,476 bytes, while query and trpc still timed out in the final five-second probe.

Static Assets configuration and ruled-out causes

B2 version metadata reports:

  • assets attached through the ASSETS binding;
  • serve_directly=true;
  • raw_run_worker_first=false;
  • /_astro/* has the immutable asset header rule.

Matching assets therefore serve before Astro/Worker application code. There is no evidence of malformed JavaScript, missing manifest entries, incomplete global upload, Astro import coupling from the carousel, or PR #195's HTML-cache change. The local files were ordinary UTF-8 assets with normal sizes/hashes, version creation completed, and other egresses retrieved the affected content. The application route, middleware, SSR, server service binding, response size, browser evaluation, and Worker application logs are not implicated; the requests never received headers.

Support request

Please investigate and repair/confirm the Cloudflare-internal Static Assets state for Worker storev2-front-staging, versions B and B2 above, specifically asset replication and/or edge fill/population for the four keys at the ULN edge during 2026-07-11T18:55Z–19:20Z.

Please confirm:

  1. whether the version asset manifests and all four content-addressed objects were fully replicated;
  2. whether any stuck asset fetch, edge fill, or regional propagation event caused zero-header responses at ULN;
  3. whether a purge, re-upload, or fresh deployment is required, and the safe remediation procedure; and
  4. what telemetry/Ray IDs or account-side diagnostics are available when the request emits no headers.

The exact internal mechanism (asset replication versus stuck edge fill) is not externally observable from Workers metadata or the version preview, so Cloudflare support assistance is required.