@epdoc/datetime — general meta.json stale after publish, versions 4.1.8 and 4.1.9 invisible to resolver

[jpravetz]

Description

After publishing @epdoc/datetime@4.1.8 (and subsequently 4.1.9), the general meta.json at https://jsr.io/@epdoc/datetime/meta.json does not include these versions. The version-specific _meta.json files exist and return 200:

• https://jsr.io/@epdoc/datetime/4.1.8_meta.json ✅ returns 200
• https://jsr.io/@epdoc/datetime/4.1.9_meta.json ✅ returns 200
  But meta.json has been serving stale content for 22+ hours:
  cf-cache-status: HIT
  age: ~80000s
  cache-control: public, max-age=14400, s-maxage=86400, stale-while-revalidate=86400
  Cache-busting with ?timestamp proves the origin has the correct data (latest: 4.1.9, includes both 4.1.8 and 4.1.9). The issue is the CDN edge cache not being purged.
  Cache control mismatch
  Source code at api/src/s3.rs defines:
  CACHE_CONTROL_MANIFEST = "public, max-age=60, s-maxage=60, stale-while-revalidate=86400"
  But the actual response uses max-age=14400, s-maxage=86400. This suggests either:

1. The production deployment has different cache-control values
2. Or the Cloudflare purge API call failed silently during these publishes
   Impact
   deno update --latest fails with:
   error: Could not find version of '@epdoc/datetime' that matches specified version constraint '^4.1.9'
   Since Deno's resolver reads from meta.json, new versions are invisible to all consumers until the CDN cache refreshes.

[jpravetz]

This is a reoccurring problem. After a successful publish of a package, deno update --latest isn't always seeing the new update. If it relies on meta.json then that is likely the problem.

As an example, I just now published @epdoc/logger and deno update isn't picking it up, with https://jsr.io/@epdoc/logger/meta.json having "latest": "1003.3.50". Meanwhile https://jsr.io/@epdoc/logger/1003.3.51_meta.json returns 200. The problem seems† to clear itself after edge caches timeout after a day.

I also tried yanking a previous version, to see if that would force the meta.json to be updated. But it doesn't. Yesterday I tried publishing an even later version and that too didn't force an update. It seems† that once the meta.json is "stuck" it stays that way for the 24 hours.

† seems = I can't say for sure

[jpravetz]

This appears to be fixed now, along with a number of other publishing performance issues that have been evident during the past week.

[jpravetz]

The issue is not resolved. I am again finding cases where meta.json is showing outdated information. I publish pkgA, the page for pkgA shows it is updated. I run deno update --latest in pkgB, pkgB doesn't see the update.

[marianmeres]

Seeing the identical failure on @marianmeres/design-tokens as of 2026-06-27T13:19Z — adding a data point in case it helps prioritize.

The aggregate meta.json has been stuck for ~5.75 hours and survived four consecutive publishes (1.10.0 → 1.10.1 → 1.11.0 → 1.12.0) without the publish purge ever invalidating it. Version-specific _meta.json and source files serve fine — only the aggregate listing is stale, so Deno's resolver fails with Could not find version of '@marianmeres/design-tokens' that matches specified version constraint '^1.12.0'.

Same cache-control mismatch you flagged: the object is served with max-age=14400, s-maxage=86400 (24h), so it won't self-heal until ~24h after it was cached.

Reproduction

# Stale: edge-cached aggregate listing (what Deno reads)
curl -sI https://jsr.io/@marianmeres/design-tokens/meta.json | grep -iE 'cf-cache-status|age|cf-ray|cache-control'
curl -s  https://jsr.io/@marianmeres/design-tokens/meta.json | python3 -c 'import sys,json;print("latest:",json.load(sys.stdin)["latest"])'
#   cf-cache-status: HIT
#   age: 20671
#   cf-ray: a124bea2ca18b183-BTS          (CF PoP: BTS / Bratislava)
#   cache-control: public, max-age=14400, s-maxage=86400, stale-while-revalidate=86400
#   latest: 1.9.0     <-- WRONG

# Correct: same URL with a cache-busting query (different CF cache key -> origin)
curl -s "https://jsr.io/@marianmeres/design-tokens/meta.json?cb=$(date +%s)" \
  | python3 -c 'import sys,json;print("latest:",json.load(sys.stdin)["latest"])'
#   latest: 1.12.0    <-- CORRECT (origin is fine)

# Per-version meta + source files serve correctly (not affected):
curl -s -o /dev/null -w '%{http_code}\n' https://jsr.io/@marianmeres/design-tokens/1.12.0_meta.json   # 200
curl -s -o /dev/null -w '%{http_code}\n' https://jsr.io/@marianmeres/design-tokens/1.12.0/src/mod.ts  # 200

Timeline (UTC, 2026-06-27)

Event	Time
Stale edge object first cached (date − age)	07:35:08
Publish 1.10.0	08:11:23
Publish 1.10.1	08:42:46
Publish 1.11.0	10:34:05
Publish 1.12.0	12:59:42
Observed still stale (age: 20671, latest: 1.9.0)	13:19:39

The cached object predates all four publishes and was invalidated by none of them; its age grows monotonically across requests (never revalidated).

Impact: deno add/install/update for any range requiring ≥1.10.0 fails. Only manual deno.lock pinning to the exact version works around it.

Could a maintainer purge the Cloudflare cache for @marianmeres/design-tokens/meta.json? Happy to run further diagnostics (additional headers, other PoPs, etc.).