What causes "Worker was destroyed." in mozilla/pdf.js?

Treat this as a benign late-arrival error after destroy; the document is already closing.

mozilla/pdf.js · error · Error

Worker was destroyed.

Error message

Worker was destroyed.

What it means

A generic Error inside the WorkerTransport's FetchBinaryData message handler: the worker asked the main thread to fetch binary data (image/font stream) but the transport has already been destroyed (this.destroyed). The handler refuses to fulfill the request because the document is gone. This is a non-MOZCENTRAL code path.

Source

Thrown at src/display/api.js:2914

        case "Pattern":
          pageProxy.objs.resolve(id, imageData);
          break;
        default:
          throw new Error(`Got unknown object type ${type}`);
      }
    });

    messageHandler.on("DocProgress", data => {
      if (this.destroyed) {
        return; // Ignore any pending requests if the worker was terminated.
      }
      this.#onProgress(data);
    });

    if (typeof PDFJSDev === "undefined" || !PDFJSDev.test("MOZCENTRAL")) {
      messageHandler.on("FetchBinaryData", async data => {
        if (this.destroyed) {
          throw new Error("Worker was destroyed.");
        }
        if (!this.binaryDataFactory) {
          throw new Error(
            "`BinaryDataFactory` not initialized, see the `useWorkerFetch` parameter."
          );
        }
        return this.binaryDataFactory.fetch(data);
      });
    }
  }

  getData() {
    return this.messageHandler.sendWithPromise("GetData", null);
  }

  saveDocument() {
    if (this.annotationStorage.size <= 0) {
      warn(

View on GitHub (pinned to 5903d58d58)

Solutions

Treat this as a benign late-arrival error after destroy; the document is already closing.
Avoid issuing new page/render requests while a destroy is pending.
Await loadingTask.destroy() before releasing references, so late worker messages have a settled transport.

Defensive patterns

Strategy: try-catch

Validate before calling

// Suppress late binary-fetch requests once teardown has started.
if (doc && !doc.destroyed) {
  await page.getTextContent();
}

Try / catch

// The error surfaces on the worker side; ensure await loadingTask.destroy()
// completes before releasing refs so late messages have a settled transport.
try {
  await doc.destroy();
} catch (e) {
  if (/Worker was destroyed/.test(e.message)) return;
  throw e;
}

Prevention

Await loadingTask.destroy() so the transport settles before you release it.
Stop issuing page/render requests once destroy begins.
Treat late 'Worker was destroyed.' errors after close as benign.

When it happens

Trigger: The worker emits a FetchBinaryData request after doc/loadingTask.destroy() began; rapid destroy while lazy image/font fetching is still in flight; range-loaded documents where the worker requests data after teardown.

Common situations: Closing a document tab/page while background image decoding is active; aggressive cleanup in viewers; memory-pressure driven destroys.

Related errors

AI-assisted analysis of mozilla/pdf.js@5903d58d58 (2026-08-13). Data as JSON: /api/errors/d9b8f71524c39ed7. Report an issue: GitHub.