`Cannot set property message of ... which has only a getter` when an error happens during instrumentation hook being require'd

[SeriousBug]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: linux
      Arch: x64
      Version: #1 ZEN SMP PREEMPT_DYNAMIC Tue, 08 Aug 2023 22:13:48 +0000
    Binaries:
      Node: 18.17.1
      npm: 9.6.7
      Yarn: 1.22.19
      pnpm: 8.6.12
    Relevant Packages:
      next: 13.4.20-canary.2
      eslint-config-next: 13.4.13
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.6
    Next.js Config:
      output: N/A

Which area(s) of Next.js are affected? (leave empty if unsure)

No response

Link to the code that reproduces this issue or a replay of the bug

https://github.com/SeriousBug/nextjs-error-repro

To Reproduce

Enable instrumentationHook experimental feature, then in the instrumentation.ts throw an error where the message field is a getter. This will cause the error Cannot set property message of ... which has only a getter. A similar error occurs if the error was not an object.

Describe the Bug

The bug is caused by this line which incorrectly assumes that the error must have a message field, which results inside the catch block:

next.js/packages/next/src/server/dev/next-dev-server.ts

Line 566 in 1e3920c

err.message = `An error occurred while loading instrumentation hook: ${err.message}`

I encountered this issue because I was parsing data with Zod at the top level of instrumentation.ts, which throws a custom error with a getter message field.

Expected Behavior

A concise error message should still be displayed if the message field can not be overwritten.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

[BellCubeDev]

I experienced this bug just a little bit ago in development of an instrumentation hook in 14.2.4. If the err.message property cannot be set for whatever reason, this will cause an error. Some safer approaches to consider:

• Checking if the err.message property exists as a property and can be written using Object.getOwnPropertyDescriptor() before attempting to overwrite it (perhaps use one of the methods below as a fallback if it isn't writable?)
  • In my case, no descriptor would be returned. However, ZodError defines a get message() in its class.
• Overwriting the err.message property through the use of a method such as Object.assign() or Object.defineProperty()
• Logging a message and letting the error go through (ideally using try/finally rather than try/catch)
• Logging the error object and throwing a new error (something I don't recommend in the case that the user has a custom server setup)

A real-world example of a library whose error does not have a writable message would be Zod with their ZodError class. This is where my error originated from.

Additionally, I recommend against using the any type for nearly anything—especially errors. A better practice would be to type the error as unknown and narrow it through TypeScript directly. While it may not have prevented this bug directly, it's possible that typing an error as unknown would help a developer realize that anything at all could be used with throw, triggering more thoughtfulness when attempting to read/write with the received value.