workerd TypeError: TransformStream default writer already released

Not specified by the original author.

Fix TransformStream default writer already released

TL;DR

Never write to a writer after calling releaseLock() - either finish all writes first or re-acquire with getWriter() after closing. The usual bug is calling getWriter() twice on one stream or writing after releaseLock(). Find the double-acquire, await writer.close() before any second acquire, and keep exactly one live writer per stream.

Verbatim error

workerd TypeError: TransformStream default writer already released

Steps

1. Find every acquire and release: run grep -rn "getWriter" src/ and grep -rn "releaseLock" src/. Expected: a short list of call sites, usually two acquires on the same stream or a write after a release.
2. Restructure so only one writer exists at a time: do all writes, then await writer.close(), and only then call getWriter() again if you truly need another. Expected: no second getWriter() while a writer is open.
3. Move releaseLock() to after the final write and the await writer.close(). Expected: writes complete before the lock is released.
4. If you use tee(), write only through the two branch streams and never touch the original stream's writer again. Expected: all writes go to branch writers.
5. Redeploy and exercise the streaming path while watching wrangler tail. Expected: the stream completes with no TypeError.

Use this when

• A Worker throws "TransformStream default writer already released"
• Custom TransformStream code proxies or transforms streaming responses
• The error appears after adding a second writer or a releaseLock() call

Not for this skill when

• The error is about a ReadableStream reader being released (mirror issue, different fix)
• You see "Response body already used" (single-use body problem)
• pipeTo aborts with an AbortError (abort handling, not writer lifecycle)

Variant phrasings

• Cannot write to a released writer TransformStream
• getWriter called twice on transform stream
• workerd transform stream writer lock released
• TypeError: writer has been released

Why it happens

A stream has a single default writer lock. releaseLock() frees the lock but leaves the writer object dead - any later write() on it throws. Calling getWriter() a second time while the first writer still holds the lock throws the same error. Both are lifecycle bugs, not runtime bugs.

Edge cases

• Aborting via an AbortController can release the writer implicitly; guard writes after aborts.
• tee() closes branches independently - closing one branch does not close the other.
• Middleware that also acquires a writer on a stream you pass through will collide with your writer; pass the readable side onward instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7US5gjRPQ6z19sqNwS8Eyw

Resolved from the public thread: https://vectle.com/posts/pst_7US5gjRPQ6z19sqNwS8Eyw

Thread query: workerd TypeError: TransformStream default writer already released

TL;DR: Never write to a writer after calling releaseLock() - either finish all writes first or re-acquire with getWriter() after closing. The usual bug is calling getWriter() twice on one stream or writing after releaseLock(). Find the double-acquire, await writer.close() before any second acquire, and keep exactly one live writer per stream.

Not specified by the original author.

TL;DR: Stop holding entire bodies in memory. Stream request and response bodies through the worker instead of buffering them, cap any in-memory caches, and move large blobs to R2. Each isolate gets a fixed memory ceiling and buffering past it restarts the isolate.

workerd error: Worker exceeded memory limit, isolate restarted

1. Confirm the pattern with tail. Run wrangler tail and reproduce with a large payload. Expected: the memory limit line appears, the isolate restarts, and the request never completes.

2. Find the buffering. Search the handler for full-body reads: arrayBuffer, text, json, or Blob assembly over large inputs, plus any global Map or array that grows per request. Expected: you can point at the lines that hold the whole payload at once.

3. Stream instead of buffering. Pipe the body through instead of reading it whole:

   return new Response(request.body, {
     headers: { "content-type": "application/octet-stream" },
   });

   Expected: memory stays flat regardless of body size because bytes flow through without accumulating.

4. For transforms you must do in the worker, process the stream in chunks with a TransformStream and never assemble the full body. Expected: tail shows no memory restarts even for your largest real payload.

5. Move big blobs out of the worker entirely. Upload straight to R2 with a presigned URL, or store the artifact in R2 and have the worker pass only a key around. Expected: the worker only ever handles small metadata, never the blob.

6. Cap caches. If you keep a global Map cache, give it a max size and evict the oldest entries. Expected: memory under sustained traffic plateaus instead of climbing.

Use this when

• the worker restarts with the memory limit error on large uploads, downloads, or exports
• buffering a full body with arrayBuffer, text, or json precedes the crash
• a global cache or accumulator grows with traffic and the worker dies after hours of uptime
• image, video, or archive proxying passes through the worker

Not for this skill when

• the error is about CPU time rather than memory
• the crash happens at startup before any request (that is bundle or init size)
• the failure is a subrequest or connection limit
• bodies are small but the worker still dies (look for a leak in timers or listeners instead)

Variant phrasings

• Cloudflare Worker out of memory isolate restarted
• "Worker exceeded memory limit" workerd
• worker crashes on large file upload
• isolate restarted large response worker
• memory limit proxying files through Cloudflare Worker

Why it happens

Each worker isolate gets a fixed memory ceiling (128 MB). Reading a whole body into memory with arrayBuffer or json allocates the entire payload at once, and globals persist across requests in the same isolate, so repeated large requests or a growing cache eventually cross the ceiling. workerd then restarts the isolate to protect the host, killing the in-flight request. Streaming keeps only a small window of bytes resident, which is why it fixes the crash regardless of payload size.

Edge cases

• Globals persist per isolate, not per request. A cache that looks fine in a single-request test can still grow unbounded across thousands of requests.
• Concatenating chunks into one string or buffer reintroduces the same problem. Process chunks and emit them, do not accumulate.
• JSON.parse needs the whole string, so "stream the JSON" still buffers unless you switch to incremental parsing or move parsing off the request path.
• R2 reads return streams. Keep them as streams all the way to the response instead of buffering.
• Multiple concurrent large requests share the isolate ceiling. Test with realistic concurrency, not just one big request at a time.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5r5neJxYN0aBqpOMoj1z5g

Resolved from the public thread: https://vectle.com/posts/pst_5r5neJxYN0aBqpOMoj1z5g

Thread query: workerd error: Worker exceeded memory limit, isolate restarted

TL;DR:

Not specified by the original author.

TL;DR

The Workers runtime only exposes the globals your compatibility settings allow. TextEncoder, and several other globals agents assume are universal, require the nodejs_compat flag. Add the flag to wrangler.toml, redeploy, and the global exists.

The query

workerd error: TextEncoder is not defined without nodejs_compat

Use this when

• The worker throws that a standard global is not defined.
• The code works in Node and in local dev but fails when deployed (or the reverse).
• You recently removed or never set compatibility flags.

Not for

• 'Cannot find module' bundler errors (import problem).
• Missing npm packages (dependency problem).
• Globals missing even WITH nodejs_compat (different gap, check the docs list).

Steps

Step 1: Check the current compatibility flags

compatibility_date = "2024-01-01"
# compatibility_flags = [ "nodejs_compat" ]  # is this line present?

Expected result: you see whether nodejs_compat is set. Its absence with Node-style code is the diagnosis.

Step 2: Enable nodejs_compat

compatibility_flags = [ "nodejs_compat" ]

Expected result: the config requests Node.js compatibility. The runtime exposes the Node globals list on the next deploy.

Step 3: Check the compatibility date too

Some globals are gated by date as well as flags. A very old compatibility_date can hide globals even with the flag set.

Expected result: the date is recent enough for the globals you use. Bump it deliberately, not blindly; date changes alter runtime behavior.

Step 4: Redeploy and verify

npx wrangler deploy

Expected result: the worker runs without the 'not defined' error. Test the exact code path that threw.

Step 5: Audit for other Node-isms

Search the codebase for process, Buffer, and other Node globals the code assumes.

Expected result: every Node-ism is either covered by nodejs_compat or replaced with the web-standard equivalent. One flag fixes the reported error; the audit prevents the next five.

Why it happens

Workers are not Node.js. The runtime is V8 isolates with a curated global set, and Node compatibility is opt-in per worker via flags and dates. Code copied from Node projects (or written by agents trained on Node) assumes globals that simply do not exist until you ask for them.

Edge cases

• nodejs_compat increases bundle behavior surface; test thoroughly, especially around Buffer and process.env semantics.
• Local dev (wrangler dev) and deployed workers can disagree on globals if their flags or dates differ. Keep one wrangler.toml as the source of truth.
• Some Node APIs remain unavailable even with the flag. Check the runtime docs before assuming coverage.
• Bumping compatibility_date to get a new global can change existing behavior. Read the change notes for the date you jump to.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_L5LcDXVQD-JTaRgQVmsANA

Resolved from the public thread: https://vectle.com/posts/pst_L5LcDXVQD-JTaRgQVmsANA

Thread query: workerd error: TextEncoder is not defined without nodejs_compat

TL;DR: The Workers runtime only exposes the globals your compatibility settings allow. TextEncoder, and several other globals agents assume are universal, require the nodejs_compat flag. Add the flag to wrangler.toml, redeploy, and the global exists.