adapter-node broken in next.153

[kamholz]

Describe the bug

I recently updated kit from next.151 to next.153 and now I am seeing an odd error when I submit a POST request to an endpoint:

node:internal/errors:464
    ErrorCaptureStackTrace(err);
    ^

RangeError [ERR_HTTP_INVALID_STATUS_CODE]: Invalid status code: ERR_HTTP_INVALID_STATUS_CODE
    at new NodeError (node:internal/errors:371:5)
    at ServerResponse.writeHead (node:_http_server:275:11)
    at ServerResponse.writeHead (file://.../repo/app/build/index.js:21366:26)
    at ServerResponse._implicitHeader (node:_http_server:266:8)
    at ServerResponse.end (file://.../repo/app/build/index.js:21516:14)
    at Polka.onError (file://.../repo/app/build/index.js:21734:9)
    at next (file://.../repo/app/build/index.js:21798:42)
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  code: 'ERR_HTTP_INVALID_STATUS_CODE'
}

This error causes the server to terminate.

Everything in this code path has worked fine for a couple months, all the way up to next.151. I've verified that the error only occurs in adapter-node, not under dev/preview. This issue renders my app unusable so I've reverted to next.151 until I can figure out what's going on. It could be something in my code but seems more likely to be an issue with adapter-node.

Reproduction

I'll work on this but wanted to report it first because this is a serious bug.

Logs

No response

System Info

System:
    OS: macOS 11.5.1
    CPU: (8) arm64 Apple M1
    Memory: 977.19 MB / 16.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 16.6.2 - /opt/homebrew/bin/node
    npm: 7.20.3 - /opt/homebrew/bin/npm
  Browsers:
    Chrome: 92.0.4515.131
    Safari: 14.1.2
  npmPackages:
    @sveltejs/adapter-node: ^1.0.0-next.42 => 1.0.0-next.42 
    @sveltejs/kit: ^1.0.0-next.153 => 1.0.0-next.153 
    svelte: ^3.41.0 => 3.41.0

Severity

blocking all usage of SvelteKit

Additional Information

No response

[vfilatov]

I second that.

[vfilatov]

It works fine in dev, but fails in production build, the following workaround works for me
build/index.js: function parse_body

from

const text = () => new TextDecoder(headers["content-encoding"] || "utf-8").decode(raw);

to

  const text = () => {
    if (typeof raw === "string")
      return raw;
    return new TextDecoder(headers["content-encoding"] || "utf-8").decode(raw)
  };

[acoyfellow]

Thirded.

[benmccann]

This is probably due to #2215

@JeanJPNM any chance you could take a look at what's going on?

[camargo]

@benmccann Has the latest version of @sveltejs/adapter-node been published to NPM? Version 1.0.0-next.42 still has the old getRawBody before #2215, which seems to be causing this error.

[JeanJPNM]

I can't reproduce the issue.
From what I see from @vfilatov 's solution, it looks like the raw body can still be a string, when it shouldn't

[JeanJPNM]

Sorry, I forgot to update the dependencies of my testing repo.

The issue can be reproduced, and its here:

Here is the build output of adapter-node:

function getRawBody(req) {
  return new Promise((fulfil, reject) => {
    const h2 = req.headers;
    if (!h2["content-type"]) {
      return fulfil("");
    }
    req.on("error", reject);
    const length = Number(h2["content-length"]);
    if (isNaN(length) && h2["transfer-encoding"] == null) {
      return fulfil("");
    }
    // ....
    req.on("end", () => {
      const [type] = (h2["content-type"] || "").split(/;\s*/);
      if (isContentTypeTextual(type)) {
        const encoding3 = h2["content-encoding"] || "utf-8";
        return fulfil(new TextDecoder(encoding3).decode(data));
      }
      fulfil(data);
    });

So yes, the issue should be fixed by releasing a new version of adapter-node.

But that got me curious: Why does adapter-node copy the code of getRawBody durings it's build time instead of copying the code while the user's project is being compiled (like adapter-vercel does)?

[benmccann]

Why does adapter-node copy the code of getRawBody durings it's build time instead of copying the code while the user's project is being compiled (like adapter-vercel does)?

I think it's because adapter-node uses Rollup while adapter-vercel does not, so it probably gets bundled for adapter-node and not adapter-vercel

[benmccann]

thanks for tracking this down. I've kicked off a new release