Custom properties on native `Error` objects thrown from a worker thread are lost

[doff6]

Description

Just see the reproduction below.

Reproduction

worker.js:

import { serializeError } from "serialize-error";

export function fn1() {
  throw Object.assign(new Error("ERROR"), { foo: "bar" });
}

export function fn2() {
  // `serializeError()` converts a native Error object into a non-native one.
  throw serializeError(Object.assign(new Error("ERROR"), { foo: "bar" }));
}

main.js:

import path from "path";
import { pathToFileURL } from "url";
import assert from "assert";
import Piscina from "piscina";

const worker = new Piscina({
  filename: pathToFileURL(path.join(import.meta.dirname, "worker.js")).href,
});

try {
  await worker.run(null, { name: "fn1" });
} catch (error) {
  assert.strictEqual(error.message, "ERROR");
  // Custom properties are unexpectedly lost.
  assert.strictEqual(error.foo, undefined);
  assert.deepStrictEqual(Object.keys(error), []);
}

try {
  await worker.run(null, { name: "fn2" });
} catch (error) {
  assert.strictEqual(error.message, "ERROR");
  // Custom properties are reserved.
  assert.strictEqual(error.foo, "bar");
  // Native error properties are properly handled by `serializeError()` as well.
  assert.deepStrictEqual(Object.keys(error), [
    "foo",
    "name",
    "message",
    "stack",
  ]);
}

Environment

• OS: WSL1 on Windows 10 22H2
• Node.js version: 26.5.0
• Piscina version: 5.3.2

Expected Behavior

Of course, those custom properties should be perfectly reserved. Certain properties of an error object are often crucial to the logic of the code; for example, the error.code property in better-sqlite3:
https://github.com/WiseLibs/better-sqlite3/blob/f8e2d541208281368129929a96f70f937c0735ef/lib/sqlite-error.js#L10
I stumbled across this issue by chance. For others who haven’t noticed it yet, this has likely caused logical errors in their code without them realising it.

[metcoder95]

I'm unable to reproduce it, tried on v5 and v6-rc; as well as latest Node v26 and see the expected result.

Can you try to isolate it and not use Piscina but rather Worker Threads directly? It is possible that is a problem on Windows for node:worker_threads

[doff6]

@metcoder95 Okay, to be precise, it's not Windows and should be Debian 13 but with an older & custom Linux kernel:

$ uname -a
Linux DESKTOP-WIN 4.4.0-19041-Microsoft #5794-Microsoft Mon Apr 07 17:55:00 PST 2025 x86_64 GNU/Linux

I'll have another try. Thanks for your reply.

[doff6]

I rewrote the reproduction code using node:worker_threads and got some interesting results.

worker.js:

const { parentPort, workerData } = require("node:worker_threads");
const { serializeError } = require("serialize-error");

const functionMap = {
  fn1() {
    return Object.assign(new Error("ERROR"), { foo: "bar" });
  },
  fn2() {
    return serializeError(Object.assign(new Error("ERROR"), { foo: "bar" }));
  },
  fn3() {
    throw Object.assign(new Error("ERROR"), { foo: "bar" });
  },
};

parentPort.postMessage(functionMap[workerData]());

main.js:

const { Worker } = require("node:worker_threads");
const path = require("node:path");
const assert = require("node:assert");

function runWorker(workerData) {
  return new Promise((resolve, reject) => {
    const worker = new Worker(path.join(__dirname, "worker.js"), {
      workerData,
    });
    worker.on("message", resolve);
    worker.once("error", reject);
    worker.once("exit", (code) => {
      if (code !== 0)
        reject(new Error(`Worker stopped with exit code ${code}`));
    });
  });
}

(async function runTests() {
  {
    const error = await runWorker("fn1");
    assert.strictEqual(error.name, "Error");
    assert.strictEqual(error.message, "ERROR");
    assert.strictEqual(typeof error.stack, "string");
    // Custom properties are lost.
    assert.strictEqual(error.foo, undefined);
    assert.deepStrictEqual(Object.keys(error), []);
  }

  {
    const error = await runWorker("fn2");
    assert.strictEqual(error.name, "Error");
    assert.strictEqual(error.message, "ERROR");
    assert.strictEqual(typeof error.stack, "string");
    // Custom properties are preserved.
    assert.strictEqual(error.foo, "bar");
    // Native error properties are properly handled by `serializeError()` as well.
    // But these properties are all enumerable now.
    assert.deepStrictEqual(Object.keys(error), [
      "foo",
      "name",
      "message",
      "stack",
    ]);
  }

  try {
    await runWorker("fn3");
  } catch (error) {
    assert.strictEqual(error.name, "Error");
    assert.strictEqual(error.message, "ERROR");
    assert.strictEqual(typeof error.stack, "string");
    // Custom properties are preserved.
    assert.strictEqual(error.foo, "bar");
    // Only the custom property is enumerable, the native properties are non-enumerable as they were originally.
    assert.deepStrictEqual(Object.keys(error), ["foo"]);
  }
})();

In fn1 & fn2, I didn't throw the error; I just passed it like a successful value using parentPort.postMessage(). Then I reproduced exactly what I got with Piscina — the custom properties are lost and can be preserved by using serialize-error.

In fn3, I just threw the error, and then node:worker_threads captured it & passed it back to the main thread. In this case the custom properties were preserved, but with a slightly different behavior than serialize-error. The native properties (name, message & stack) remained non-enumerable just as they were originally, while serialize-error would make them enumerable (Object.keys(error) is ["foo"] in fn3 while Object.keys(error) is ["foo","name",...] in fn2).

If you run this new code, you might still not see any assertion errors, which actually means you’re getting exactly the same result as I did, i.e. the custom properties are lost. In the code, I simply described what I actually got, not what was expected. I’m sorry for the confusion this caused.

I did some research on the processing behind it. parentPort.postMessage() uses the HTML structured clone algorithm. It's said that structuredClone() will ignore those custom properties when cloning an Error object. So it's by design and not considered a bug of Node.js. We may have no other choice but to handle these properties ourselves in Piscina, at least for now.

[metcoder95]

Good call out, I missed that from the structuredClone algorithm; so definitely it is sadly a limitation when throwing a native Error instance

I believe is worth it to document this for people facing the same behavior.
Would you like to send a PR for that?