Node 20: errors with util.inspect.custom raised in loader thread not serialized/deserialized correctly

Version

v20.2.0

Platform

No response

Subsystem

No response

What steps will reproduce the bug?

Throw an error with a custom inspect symbol in worker thread, which is then serialised and deserialised to be displayed by main thread.

Investigating a bug in ts-node (TypeStrong/ts-node#2026) I ran into some issues with how errors in (loader) worker threads are handled.

util.inspect.custom is only checked in own properties (https://github.com/nodejs/node/blob/main/lib/internal/error_serdes.js#L137), ignoring it if the error was created using a class constructor (see https://github.com/TypeStrong/ts-node/blob/7af5c48864b60576e471da03c064f325ce37d850/src/index.ts#L432-L464)
Errors with custom inspect methods are not displayed correctly by call to internalBinding('errors').triggerUncaughtException

node:internal/process/esm_loader:42
      internalBinding('errors').triggerUncaughtException(
                                ^
[Object: null prototype] {
  [Symbol(nodejs.util.inspect.custom)]: [Function: [nodejs.util.inspect.custom]]
}

Errors defined by classes inheriting from Error don't appear to trigger the check here: https://github.com/nodejs/node/blob/main/lib/internal/error_serdes.js#L120

let a = new Error("hmm?")
Object.prototype.toString(a)
> "[object Object]"

How often does it reproduce? Is there a required condition?

Every time an error is raised in loader worker thread.

What is the expected behavior? Why is that the expected behavior?

Errors using custom inspect symbol raised in threads should serialise correctly

What do you see instead?

[Symbol(nodejs.util.inspect.custom)]: [Function: [nodejs.util.inspect.custom]]

Additional information

No response

The title says "loader thread", but I assume that's true for any worker thread, right?

One of the issues seems specific to the error handling code in process/esm_loader. Others seem to affect all error serialisation.

Can you share a minimal repro?

@aduh95

@aduh95 would the repro I made for node-ts do?

TypeStrong/ts-node-repros#33

A minimal repro would ideally not include any code to be downloaded from the internet, ideally a list of commands that can be copy pasted from the web browser to a terminal.

util.inspect.custom is only checked in own properties

I've opened #48306 to address this.

2. Errors with custom inspect methods are not displayed correctly by call to internalBinding('errors').triggerUncaughtException

It has nothing to do with the custom inspect method, triggerUncaughtException will not run any JS, it generates the error message using v8::Exception::createMessage so I think what you see is the expected output.

node/src/node_errors.cc

Lines 1005 to 1017 in 6700aac

    
           static void TriggerUncaughtException(const FunctionCallbackInfo<Value>& args) { 
        
             Isolate* isolate = args.GetIsolate(); 
        
             Environment* env = Environment::GetCurrent(isolate); 
        
             Local<Value> exception = args[0]; 
        
             Local<Message> message = Exception::CreateMessage(isolate, exception); 
        
             if (env != nullptr && env->abort_on_uncaught_exception()) { 
        
               ReportFatalException( 
        
                   env, exception, message, EnhanceFatalException::kEnhance); 
        
               Abort(); 
        
             } 
        
             bool from_promise = args[1]->IsTrue(); 
        
             errors::TriggerUncaughtException(isolate, exception, message, from_promise); 
        
           }

3. Errors defined by classes inheriting from Error don't appear to trigger the check here: https://github.com/nodejs/node/blob/main/lib/internal/error_serdes.js#L120
let a = new Error("hmm?")
Object.prototype.toString(a)
> "[object Object]"

You forgot .call, try e.g. Object.prototype.toString.call(new class A extends TypeError{}).

I'm not sure what this ticket is about, could you please share a minimal repro that includes steps to reproduce the issue (without needing to download code from the internet), the expected output, and what you see instead please?

lib: add support for inherited custom inspection methods

Pointless issue. Still receive an error and only this output:

node:internal/process/esm_loader:40
      internalBinding('errors').triggerUncaughtException(
                                ^
[Object: null prototype] {
  [Symbol(nodejs.util.inspect.custom)]: [Function: [nodejs.util.inspect.custom]]
}

Node.js v18.19.0
error Command failed.
Exit code: 1

Getting the same error on node 20. If I change it to mjs it runs perfectly, but for some reason it just can't run in esm loader. Tested in both node 18 and 20.

Changing this in tsconfig.json seems to fixed the issue for me (shows actual error)

  "ts-node": {
    "experimentalSpecifierResolution": "node",
    "transpileOnly": true,
    "esm": true,
  },

Getting the same error on node 20. If I change it to mjs it runs perfectly, but for some reason it just can't run in esm loader. Tested in both node 18 and 20.

Changing this in tsconfig.json seems to fixed the issue for me (shows actual error)
  "ts-node": {
    "experimentalSpecifierResolution": "node",
    "transpileOnly": true,
    "esm": true,
  },

Using "transpileOnly": true is already enough for me to make it work.

I had similar error:
node:internal/process/esm_loader:40 internalBinding('errors').triggerUncaughtException( ^ [Object: null prototype] { [Symbol(nodejs.util.inspect.custom)]: [Function: [nodejs.util.inspect.custom]] }
I added below suggestion about ts-node to my tsconfig.json and I saw details about the problem. I had changed module directory before and didn't noticed error. I changed directory in import statement and application started up.

I have the same error when i run Cypress in my project. It doesn't want to open and when it runs i get this error:

node:internal/modules/run_main:129
    triggerUncaughtException(
    ^
[Object: null prototype] {
  [Symbol(nodejs.util.inspect.custom)]: [Function: [nodejs.util.inspect.custom]]
}

No tsconfig options solved this issue. Any resloves yet on this? I tried to run in Node 18 and 20 but the same problem. here are the dependencies:

"dependencies": {
    "@aparajita/capacitor-biometric-auth": "^8.0.0",
    "@capacitor-community/file-opener": "^6.0.0",
    "@capacitor-firebase/analytics": "^6.0.0",
    "@capacitor/android": "^6.1.0",
    "@capacitor/app": "^6.0.0",
    "@capacitor/browser": "^6.0.1",
    "@capacitor/core": "^6.1.0",
    "@capacitor/filesystem": "^6.0.0",
    "@capacitor/ios": "^6.1.0",
    "@capacitor/share": "^6.0.1",
    "@capacitor/splash-screen": "^6.0.1",
    "@capacitor/storage": "^1.2.5",
    "@tanstack/vue-query": "^4.37.1",
    "@unocss/reset": "^0.53.6",
    "@vuelidate/core": "^2.0.3",
    "@vuelidate/validators": "^2.0.4",
    "@vueuse/core": "^10.11.0",
    "axios": "^1.7.2",
    "capacitor-blob-writer": "^1.1.16",
    "firebase": "^10.12.3",
    "floating-vue": "2.0.0-beta.24",
    "h3": "^1.12.0",
    "highcharts": "^10.3.3",
    "lodash-es": "^4.17.21",
    "naive-ui": "^2.38.2",
    "sass": "^1.77.6",
    "sass-loader": "^13.3.3",
    "swiper": "^9.4.1",
    "vite": "4.4.11",
    "vue": "^3.4.38",
    "vue-query": "^1.26.0",
    "vue-router": "^4.4.0",
    "vuelidate": "^0.7.7",
    "webpack": "^5.92.1"
  },
  "devDependencies": {
    "@antfu/eslint-config": "^1.2.1",
    "@capacitor/assets": "3.0.1",
    "@capacitor/cli": "^6.1.0",
    "@iconify-json/carbon": "^1.1.36",
    "@iconify-json/twemoji": "^1.1.15",
    "@nuxt/image": "1.1.0",
    "@nuxt/ui-templates": "^1.3.4",
    "@nuxtjs/color-mode": "^3.4.2",
    "@pinia/nuxt": "^0.4.11",
    "@types/vuelidate": "^0.7.21",
    "@unhead/vue": "^1.9.15",
    "@unocss/nuxt": "^0.46.5",
    "@vueuse/nuxt": "^9.13.0",
    "cypress": "^13.14.2",
    "eslint": "^8.57.0",
    "nuxt": "3.13.0",
    "pinia": "^2.1.7",
    "typescript": "^4.9.5"
  }

Hey everyone,

I added "logError": true in the ts-node config and was able to see the actual error instead of just the diagnostic code:

"ts-node": {
  "experimentalSpecifierResolution": "node",
  "experimentalResolver": true,
  "transpileOnly": false,
  "esm": true,
  "logError": true,
}

This helped debug the issue more effectively. Let me know if this works for you.

Had this problem when using colyseus.

Replacing dedent with ts-dedent fixed the issue for me with this in the tsconfig:

"ts-node": {
  "experimentalSpecifierResolution": "node",
  "experimentalResolver": true,
  "esm": true,
  "logError": true
}

Any fix for this?

Any fix for this?

Use the above tsconfig to find the actual error

#48207 (comment)

Getting the same error on node 20. If I change it to mjs it runs perfectly, but for some reason it just can't run in esm loader. Tested in both node 18 and 20.
Changing this in tsconfig.json seems to fixed the issue for me (shows actual error)
  "ts-node": {
    "experimentalSpecifierResolution": "node",
    "transpileOnly": true,
    "esm": true,
  },
Using "transpileOnly": true is already enough for me to make it work.

this fixed it for me ty! can someone explain why?

Navigation Menu

Repository navigation

Node 20: errors with util.inspect.custom raised in loader thread not serialized/deserialized correctly #48207

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	static void TriggerUncaughtException(const FunctionCallbackInfo<Value>& args) {
	Isolate* isolate = args.GetIsolate();
	Environment* env = Environment::GetCurrent(isolate);
	Local<Value> exception = args[0];
	Local<Message> message = Exception::CreateMessage(isolate, exception);
	if (env != nullptr && env->abort_on_uncaught_exception()) {
	ReportFatalException(
	env, exception, message, EnhanceFatalException::kEnhance);
	Abort();
	}
	bool from_promise = args[1]->IsTrue();
	errors::TriggerUncaughtException(isolate, exception, message, from_promise);
	}

Node 20: errors with util.inspect.custom raised in loader thread not serialized/deserialized correctly #48207

Description

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Activity

aduh95 commented on May 28, 2023

danrr commented on May 28, 2023

aduh95 commented on May 30, 2023

danrr commented on May 30, 2023

aduh95 commented on May 30, 2023

aduh95 commented on Jun 2, 2023

WalterWoshid commented on Dec 8, 2023

pencilcheck commented on Dec 31, 2023

coeing commented on Jan 8, 2024

malgorzataxkowal commented on Jan 26, 2024

danijezernik commented on Sep 24, 2024

vahiwe commented on Feb 2, 2025

GitOutOfMyBed commented on May 2, 2025

aminya commented on Jun 12, 2025

repulsio commented on Jul 11, 2025

aminya commented on Jul 11, 2025

ahmsaed commented on Oct 4, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions