Update bundled Deno from 2.7.14 to 2.9.x #15157

Activity

1. cderv

   added this to the v1.11 milestone on Oct 22, 2026
2. cderv

   added

   denoIssues related to denoIssues related to deno

   on Oct 22, 2026
3. mcanouil

   added

   maintenance

   on Oct 22, 2026
4. cderv commented on Oct 22, 2026

   

   cderv

   on Oct 22, 2026

   MemberAuthor

   More actions

   Found a blocking problem with this update: Deno KV values written by Deno 2.9.8 can't be read by Deno 2.7.14, reading them fails with RangeError: could not deserialize value. The other direction works, 2.9.8 reads data written by 2.7.14.

   Quarto uses Deno KV for two caches:

   • the project cache in .quarto/project-cache/
     

     quarto-cli/src/core/cache/cache.ts

     Lines 68 to 72 in 517944d

     	async init(): Promise<void> {
     	const indexPath = join(this.projectScratchDir, "project-cache");
     	ensureDirSync(indexPath);
     	this.index = await Deno.openKv(join(indexPath, "deno-kv-file"));

   • the Sass cache in the user cache directory (%LOCALAPPDATA%\quarto\sass on Windows, ~/Library/Caches/quarto/sass on macOS, ~/.cache/quarto/sass on Linux), which is shared by every Quarto version installed on the machine
     

     quarto-cli/src/core/sass.ts

     Lines 409 to 411 in 517944d

     	const cacheDir = useSessionCache
     	? join(temp.baseDir, "sass")
     	: quartoCacheDir("sass");

   I tested on Windows with a dev build on Deno 2.9.8 and Quarto 1.10.19 (Deno 2.7.14):

   • Render a project with the dev build, then with 1.10.19: ERROR: RangeError: could not deserialize value.
   • Render a single document with the dev build, then another single document with 1.10.19: same error, coming from the shared Sass cache. 1.10.19 with a fresh cache renders fine.
   • Deleting .quarto/ or the sass cache folder fixes it.
   • This is new with Deno 2.9. Quarto 1.9.38 (Deno 2.4.5) reads caches written by 1.10.19 without problem.

   So as soon as a Quarto with Deno 2.9.8 has rendered on a machine, an older Quarto on the same machine (for example the one bundled with RStudio or Positron) fails to render projects, and HTML documents through the Sass cache, until the cache is deleted. Same for a 1.10.x backport: older 1.10.x installs would break once the patch release has run. The QUARTO_DENO workaround from #15152 does it too: 1.10.19 with QUARTO_DENO pointing to Deno 2.9.8, then 1.10.19 without it, gives the same error.

   This needs a solution before we ship Deno 2.9.8. We could store the KV files under a name or folder that depends on the Deno version, so older versions never open them. Treating a deserialize error as a cache miss would only help versions that have this fix, not the ones already released.

   Deno only reproduction

   // write.ts
   const kv = await Deno.openKv(Deno.args[0]);
   await kv.set(["version"], "1.11");
   kv.close();

   // read.ts
   const kv = await Deno.openKv(Deno.args[0]);
   console.log((await kv.get(["version"])).value);
   kv.close();

   deno-2.9.8 run --unstable-kv -A write.ts kv-file
   deno-2.7.14 run --unstable-kv -A read.ts kv-file
   # RangeError: could not deserialize value
5. cderv

   added a commit that references this issue on Oct 23, 2026

   Keep Deno KV caches per V8 release branch to handle several Deno (#15180

   ...

   714c426
6. cderv commented on Oct 23, 2026

   

   cderv

   on Oct 23, 2026

   MemberAuthor

   More actions

   The KV cache problem from my previous comment is fixed by #15180, which keeps the KV stores in a folder per V8 version. I checked it with the update branch rebased on it and Quarto 1.10.19, rendering in both orders, for a project and for a single document. All renders work, and each version keeps its own cache.

   Going through the Deno 2.8 and 2.9 changes, I found three other behaviour changes that affect us.

   Network errors lose their reason

   Since denoland/deno#35618, a failed fetch throws TypeError: fetch failed, and the actual reason is only in error.cause. We only print error.message, so users don't see the host or the reason anymore. For example with quarto add https://expired.badssl.com/x.zip:

   # Quarto 1.10.19 (Deno 2.7.14)
   ERROR: TypeError: A network error occurred when attempting to inspect the extension 'https://expired.badssl.com/x.zip'. Please try again.
   
   error sending request for url (https://expired.badssl.com/x.zip): client error (Connect): invalid peer certificate: certificate expired: ...
   
   # dev build (Deno 2.9.8)
   ERROR: TypeError: A network error occurred when attempting to inspect the extension 'https://expired.badssl.com/x.zip'. Please try again.
   
   fetch failed
   

   quarto-cli/src/core/log.ts

   Lines 360 to 366 in 714c426

   	export function logError(e: unknown, defaultShowStack = true) {
   	// normalize
   	const err = asErrorEx(e, defaultShowStack);
   	// print error name if requested
   	let message = err.printName ? `${err.name}: ${err.message}` : err.message;

   This matters for this update in particular: a user behind a server using the distrusted eMudhra intermediates would get a certificate error, and only see fetch failed. We could print cause in logError.

   Port 4190 is now blocked by fetch

   Deno 2.9 blocks the Fetch standard bad ports (denoland/deno#34863). Our isPortSafe list has 4160 for sieve, but the sieve port in the Fetch list is 4190, so our random port picker can still return 4190.

   quarto-cli/src/core/port.ts

   Lines 17 to 37 in 714c426

   	function isPortSafe(port: number): boolean {
   	// cf https://superuser.com/a/188070
   	// and netwerk/base/nsIOService.cpp in Firefox's source
   	//
   	// excludes port numbers that Chrome or Firefox consider unsafe
   	return ![
   	3659, // apple-sasl / PasswordServer
   	4045, // lockd
   	4160, // sieve
   	5060, // sip
   	5061, // sips
   	6000, // X11
   	6566, // sane-port
   	6665, // Alternate IRC [Apple addition]
   	6666, // Alternate IRC [Apple addition]
   	6667, // Standard IRC [Apple addition]
   	6668, // Alternate IRC [Apple addition]
   	6669, // Alternate IRC [Apple addition]
   	6679, // osaut
   	6697, // IRC + TLS
   	7000, // As of 2024-10-21, Chrome doesn't appear to like this port anymore

   Chrome uses 9222 when it is free, otherwise a random port between 3000 and 8000. If that port is 4190, the readiness check fetch on it will always fail, until the launch times out.

   quarto-cli/src/core/cri/launch.ts

   Line 253 in 714c426

   const port = options.port ?? findOpenPort(9222);

   quarto-cli/src/core/cri/launch.ts

   Line 170 in 714c426

   const response = await fetch(`http://localhost:${port}/json/list`, {

   With a server listening on 4190, fetch("http://localhost:4190/json/list") returns 200 with Deno 2.7.14, and fails with Requests to port 4190 are blocked with Deno 2.9.8. I did not reproduce it with Chrome itself. All the other bad ports between 3000 and 8000 are already in our list.

   quarto run keeps deleting its Deno cache

   Before running a script, quarto run checks that every file of the bundled deno_std cache is also in the user cache, and if not it deletes the user cache and copies it again.

   quarto-cli/src/core/run/deno.ts

   Lines 109 to 116 in 714c426

   	if (
   	fileList.some(filesDiffer) ||
   	// perf: don't check contents; instead only look at filenames, since they're all hashed anyway
   	!directoryListingsMatch(distDenoStd, cacheDenoStd)
   	) {
   	removeIfExists(cacheDenoStd);
   	copyTo(distDenoStd, cacheDenoStd);
   	}

   The bundled cache has SQLite -shm and -wal files, and Deno 2.9.8 removes node_analysis_cache_v2-shm after a run. So the next quarto run deletes the cache, including the npm packages the script downloaded. With QUARTO_RUN_NO_NETWORK=true, a script importing an npm: package fails right after an online run:

   npm package not found in cache: "lodash-es", --cached-only is specified.
   

   Quarto 1.10.19 keeps its cache and runs the same script offline fine. Deno 2.9.8 alone, with its own DENO_DIR, also works offline, so this is the filename comparison in our code meeting a different SQLite cleanup in the new Deno.

   These three come with the Deno update, so they'll need to go with it, including in a 1.10.x backport if we do one. I am still checking the remaining items (test sanitizers now off by default in deno test, deno bundle for quarto call build-ts-extension, PDF test helpers, preview).