JSR serving stale manifest from some Cloudflare POPs

[phinnaeus]

I published a new version of my package @phinnaeus/cedrine@0.6.0 about 6 hours ago (00:56 UTC). I have an application which uses this package, so I bumped the version in my package.json and ran pnpm install to regenerate my lockfile. This worked fine from my laptop in Sydney. Unfortunately my Gitlab CI pipeline insists that this version doesn't actually exist yet. This surfaces as the following error:

? Verifying lockfile against supply-chain policies (273 entries)...
Lockfile is up to date, resolution step is skipped
Progress: resolved 1, reused 0, downloaded 0, added 0
.                                        | +121 ++++++++++++
Progress: resolved 121, reused 0, downloaded 43, added 0
Progress: resolved 121, reused 0, downloaded 54, added 0
✗ Lockfile failed supply-chain policy check (273 entries in 2.3s)
Progress: resolved 121, reused 0, downloaded 120, added 8
Progress: resolved 121, reused 0, downloaded 121, added 121, done
[ERR_PNPM_TARBALL_URL_MISMATCH] 1 lockfile entries failed verification:
  @jsr/phinnaeus__cedrine@0.6.0 could not be verified against the registry's published metadata

The reason it cant be verified against the registry's metadata is because the metadata being returned is from 16+ hours ago at this point, but only for a combination of factors: ATL Cloudflare POP + url-encoded request (GET /@jsr%2Fphinnaeus__cedrine instead of GET /@jsr/phinnaeus__cedrine). Both forms of the URL return the correct, up-to-date manifest when I hit them from Sydney. I can't seem to control what version of the URL pnpm uses unfortunately, but the fact that they are different seems clearly unintended.

The weird thing is the bad manifest response shows an age which is MUCH older than the reported max-age:

cf-ray: ...-ATL   cf-cache-status: HIT   age: 45241
cache-control: public, max-age=60, s-maxage=60
etag: "93aac0fd5366fc81165ad8702fc514fc"   (0.6.0 absent)

No idea what's going on with that. I did find a couple of possibly related issues such as #1317 and #1456.

[phinnaeus]

I've temporarily worked around this by pinning the tarball directly in my package.json

- "@phinnaeus/cedrine": "jsr:^0.6.0",
+ "@phinnaeus/cedrine": "https://npm.jsr.io/~/11/@jsr/phinnaeus__cedrine/0.6.0.tgz",

[coderbyheart]

I ran into the same problem with https://jsr.io/@nrfcloud/problem-detail, here is Claude's analysis: the encoded-path variant getting a 24h s-maxage while the canonical path gets 60s looks like a cache-config bug, and it will bite every npm install of a freshly published JSR package.

The giveaway: npm.jsr.io has two separate CDN cache objects for the same package,
depending on whether the / in the scope is percent-encoded — and npm requests the encoded form:

https://npm.jsr.io/@jsr/nrfcloud__problem-detail     latest=1.4.3  age: 27      s-maxage=60
https://npm.jsr.io/@jsr%2fnrfcloud__problem-detail   latest=1.4.1  age: 83159   s-maxage=86400, stale-while-revalidate=86400

npm's silly log confirms which one it hits:

npm http fetch GET 200 https://npm.jsr.io/@jsr%2fnrfcloud__problem-detail (cache updated)

That object was cached ~23h ago, before 1.4.2 (Aug 3, 13:25 UTC) and 1.4.3 existed, and it carries
a 24h edge TTL instead of the 60s the unencoded path gets — hence ETARGET / No matching version found. 
It's not your npm cache: I reproduced it with a throwaway --cache dir, and
--prefer-online doesn't help either since the staleness is at Cloudflare, not locally. 
The 1.4.3 tarball itself is fine (https://npm.jsr.io/~/11/@jsr/nrfcloud__problem-detail/1.4.3.tgz, 200, 15 KB).