Server crashes because `response.cause` doesn't exist

[csabaxyz]

I updated to nano v11 and started getting server crashes in my local dev environment, because of this line:

couchdb-nano/lib/nano.js

Line 131 in 26fb0e1

response.statusText = response.cause.toString()

Looks like the response doesn't have a cause property:

126 |     const responseHeaders = Object.assign({
127 |       uri: scrubURL(req.url),
128 |       statusCode
129 |     }, response.headers ? response.headers : {})
130 |     if (!response.status) {
131 |       response.statusText = response.cause.toString()
                                           ^
TypeError: undefined is not an object (evaluating 'response.cause.toString')
      at <anonymous> (/opt/src/node_modules/nano/lib/nano.js:131:38)
      at responseHandler (/opt/src/node_modules/nano/lib/nano.js:112:43)
      at <anonymous> (/opt/src/node_modules/nano/lib/nano.js:431:11)

For reference I'm using Bun instead of Node.js, so that might be the real culprit, but the fix is either response.cause?.toString() or adding a fallback cause.

[digitalextremist]

Also using Bun here @csabaxyz; and have not seen this yet.

Curious what led up to this? What operation was being performed?

Seems like your code, if it was not changed at the v11 shift, might have had a suppressed error leading up to now?

---

The stack-trace seems to start from here:

couchdb-nano/lib/nano.js

Line 431 in 26fb0e1

responseHandler(e, fetchOptions, opts, resolve, reject)

Seems responseHandler is actually being sent error rather than response is the root issue, before the apparent error.

Seems like it was the same call before the change:

26fb0e1#diff-695d68e8a3fa741f813071eb65314036c1d066217057473e897d0d33104cbe34L445

But that yes, the response.cause.toString() call is new:

26fb0e1#diff-695d68e8a3fa741f813071eb65314036c1d066217057473e897d0d33104cbe34L140

---

response.statusText seems to need to be response.cause.toString or error.message which became response.message since response might be error in the case mentioned above.

Seems like a design/theory error ( function sent wrong type on first argument ) rather than a purely syntax one, though response?.cause?.toString might silence the issue.

[csabaxyz]

Curious what led up to this? What operation was being performed?

Essentially I was in the process of implementing a minimal migration script to setup the database before the rest of the code runs, and that code runs when the Docker containers are coming online, so the initial connection can actually go to a non-existent database service. So, when the error happens the request looks like this:

{
  url: "http://couch:5984/_session",
  method: "post",
  headers: {
    accept: "application/json",
    "user-agent": "nano/11.0.0 (Node.js v24.3.0)",
    "Accept-Encoding": "deflate, gzip",
    "content-type": "application/x-www-form-urlencoded; charset=utf-8",
  },
  credentials: "include",
  body: URLSearchParams {
    "name": "***",
    "password": "***",
  },
  redirect: "error",
  signal: undefined,
  bodyTimeout: 0,
}

But you are right, when I was using v10 the error was swallowed in the retry logic. I downgraded to see what the error was before:

152 |         return
153 |       }
154 | 
155 |       log({ err: 'socket', body, headers: responseHeaders })
156 |       if (reject) {
157 |         reject(new Error(`error happened in your connection. Reason: ${response.message}`))
                     ^
error: error happened in your connection. Reason: ECONNREFUSED
      at responseHandler (/opt/src/node_modules/nano/lib/nano.js:157:16)
      at <anonymous> (/opt/src/node_modules/nano/lib/nano.js:456:13)

[digitalextremist]

Thank you for the extra context @csabaxyz; that helps and makes sense. I feel the issue is in the open now.

I suspect a refactor is needed to really fix the issue, but I put up a PR ( #358 linked above ) to think about.

By the way, you can try my branch if you feel like it. Am at-full-gallop right now and cannot stop for a bit.