Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash with "req.handle.writev is not a function" on Socket.Writable.uncork #21665

Closed
Jessidhia opened this issue Jul 5, 2018 · 49 comments
Closed
Labels
net Issues and PRs related to the net subsystem.

Comments

@Jessidhia
Copy link

  • Version: 10.6.0
  • Platform: Darwin 18.0.0 Darwin Kernel Version 18.0.0: Wed Jun 27 22:28:20 PDT 2018; root:xnu-4903.200.274.31.2~2/RELEASE_X86_64 x86_64
  • Subsystem: net

This is a node internal crash that happens with webpack-dev-server, likely with any config, only when running on node 10.6.0:

internal/stream_base_commons.js:59
  var err = req.handle.writev(req, chunks, allBuffers);
                       ^

TypeError: req.handle.writev is not a function
    at writevGeneric (internal/stream_base_commons.js:59:24)
    at Socket._writeGeneric (net.js:758:5)
    at Socket._writev (net.js:767:8)
    at doWrite (_stream_writable.js:408:12)
    at clearBuffer (_stream_writable.js:517:5)
    at Socket.Writable.uncork (_stream_writable.js:314:7)
    at connectionCorkNT (_http_outgoing.js:646:8)
    at process._tickCallback (internal/process/next_tick.js:63:19)

The same webpack-dev-server with the same config has no crash on node 10.4.1 and runs successfully.

@gireeshpunathil
Copy link
Member

a minimal reproduce please?

@MymmiJ
Copy link

MymmiJ commented Jul 11, 2018

Not OP & don't have a minimal reproduce as such unfortunately, but I'm having the same problem on my local build (Mac OS X v 10.13.4) and others have verified on the same OS. Seems to happen on build while building the ttf2woff2 module, and while running it happens with some XHRs that timeout, but sometimes it just appears to fall over with no consistent pattern. It doesn't happen every time that we build using 10.6.0, but if it doesn't happen during build it always happens at some point while running, usually within 5-20 minutes.

Building the ttf2woff2 module is the longest stage of our build process and therefore it may be just a coincidence that this error tends to throw during this particular stage (i.e. it could happen any time but this is the time it's most likely to happen statistically), or it may be that long-running processes themselves cause the issue. This is about as helpful as I can get I'm afraid, it's all I can tell from where I'm sat.

We're currently just reverting to an earlier version, we haven't found a reliable workaround.

@Jesseppi
Copy link

Im getting the same issue.
Version: 10.6.0
Platform: OSX HighSierra 10.13.6

when running webpack-dev-server, and seems to only happen when im accessing the page from IOS device.

@addaleax
Copy link
Member

Since this already has 18 upvotes: Please provide a way to reproduce this. It seems like enough people are running into this issue to make that possible…

@WesSouza
Copy link

Boy this is complicated.

I was able to create a reproducible flow for this:

  1. Clone and npm install this https://github.com/WesleydeSouza/subway-time
  2. Run HTTPS=1 node scripts/start.js
  3. Using an iOS device or simulator navigate to https://[IP]:3000
  4. Calls will start to fail

screen shot 2018-07-14 at 9 57 21 am

  1. Trying to run the server again will fail because the client still calls /eventsource repeatedly, which immediately crashes the server again.

I'm on macOS 10.14 18A326h (Mojave), and tested on iOS 11.4 simulator and a device with iOS 12, always with the same results. Desktop Chrome doesn't trigger this problem.

@danyim
Copy link

danyim commented Jul 15, 2018

I ran into this issue when I was running Node 10 in a new shell while trying to start a Node 7 project. Try rm -rf node_modules && nvm use 7 && yarn install if all else fails.

@hiroppy hiroppy added the net Issues and PRs related to the net subsystem. label Jul 20, 2018
@YvanGuidoin
Copy link

Same issue running Node v10.7.0 on Ubuntu 18.04, with the latest webpack-dev-server, and accessing with Chromium

@lundibundi
Copy link
Member

@YvanGuidoin is it possible for you to provide what are you actually running with the webpack-dev-server? As it seems that we may be able to reproduce your case much more easily than @wesleydesouza one (I actually tried that one with MacOS in VBox but I guess it's outdated enough to not trigger this bug).

@geminiyellow
Copy link

same, webpack-dev-server down.

    "webpack": "3.8.1",
    "webpack-dev-server": "2.9.4",

@WellspringCS
Copy link

WellspringCS commented Jul 26, 2018

same. Windows 10 Node v10.7.0 using angular
"@angular-devkit/build-angular": "~0.6.8",
"@angular/cli": "^6.0.8",
"@angular/compiler-cli": "6.0.9",
rebooted my machine and the problem is gone.

For now.

@YvanGuidoin
Copy link

YvanGuidoin commented Jul 26, 2018

@lundibundi I can't give you access to the code sorry ;) but I cleaned our webpack config from the "private" parts so you can see it

const path = require("path");
const webpack = require("webpack");
const autoprefixer = require("autoprefixer");
const UglifyJsPlugin = require("uglifyjs-webpack-plugin");
const MiniCssExtractPlugin = require("mini-css-extract-plugin");
const HtmlWebpackPlugin = require("html-webpack-plugin");
const { BundleAnalyzerPlugin } = require("webpack-bundle-analyzer");
const CopyWebpackPlugin = require("copy-webpack-plugin");
const OfflinePlugin = require("offline-plugin");
const WebpackPwaManifest = require("webpack-pwa-manifest");
const LodashModuleReplacementPlugin = require("lodash-webpack-plugin");
const CleanWebpackPlugin = require("clean-webpack-plugin");

const confHotReload = {
  contentBase: path.resolve(__dirname, "dist"),
  compress: false,
  historyApiFallback: true,
  hot: true,
  https: true,
  index: "index.html",
  open: false,
  inline: true,
  overlay: true,
  watchOptions: {
    poll: true,
    ignored: [/node_modules/, "**/*.d.ts"],
  },
  port: 9000,
  proxy: {
    // some apis
  },
};
const configProxy = {
  target: "https://localhost/",
  secure: false,
  changeOrigin: true,
  ws: true,
  proxyTimeout: 60000,
};

const getPlugins = function getPlugins(isProd, isHot) {
  const pluginsProduction = [
    new CleanWebpackPlugin(["dist/*"]),
    new LodashModuleReplacementPlugin(),
    new OfflinePlugin({
      appShell: "/",
      externals: ["https://fonts.googleapis.com/css?family=Montserrat", "/"],
      ServiceWorker: {
        minify: true,
        events: true,
      },
      autoUpdate: true,
      AppCache: false,
      excludes: ["**/*.d.ts", "**/locale/*.js"],
    }),
    new WebpackPwaManifest({
      name: "Test",
      short_name: "Test",
      background_color: "#ffffff",
      fingerprints: true,
      inject: true,
      theme_color: "#ff7f27",
      start_url: "/",
      icons: [
        {
          src: path.resolve("public/splash.png"),
          sizes: [36, 128, 192, 256, 384, 512], // multiple sizes
        },
      ],
    }),
    new BundleAnalyzerPlugin({
      analyzerMode: "static",
      openAnalyzer: false,
      logLevel: "error",
    }),
  ];

  const commonsPlugins = [
    new webpack.DefinePlugin({
      "process.env": {
        NODE_ENV: JSON.stringify(isProd ? "production" : "development"),
        BROWSER: true,
      },
      DOMAIN_API: JSON.stringify(process.env.DOMAIN_API),
    }),
    new webpack.IgnorePlugin(/^\.\/locale$/, /moment$/), // not included in bundle
    new HtmlWebpackPlugin({
      template: "public/index.html",
      filename: "index.html",
      inject: true,
      chunksSortMode: "none",
      cache: isHot,
      minify: {
        preserveLineBreaks: true,
        html5: true,
        removeComments: false,
        collapseWhitespace: true,
      },
      favicon: "public/favicon.png",
    }),
    new HtmlWebpackPlugin({
      template: "public/unsupported.html",
      filename: "unsupported.html",
      inject: false,
      chunksSortMode: "none",
      cache: isHot,
      minify: {
        preserveLineBreaks: true,
        html5: true,
        removeComments: false,
        collapseWhitespace: true,
      },
      favicon: "public/favicon.png",
    }),
    new MiniCssExtractPlugin({
      filename: "[name].css",
      chunkFilename: "[id].css",
    }),
    new CopyWebpackPlugin([
      {
        context: "node_modules/moment/locale",
        from: "*",
        to: "./locale/",
      },
      {
        context: "node_modules/videojs-contrib-hls/dist",
        from: "videojs-contrib-hls.min.js",
        to: "./videojs/",
      },
      {
        context: "node_modules/video.js/dist",
        from: "video.min.js",
        to: "./videojs/",
      },
      {
        context: "public/",
        from: "robots.txt",
        to: ".",
      },
    ]),
  ];
  if (isHot) {
    commonsPlugins.push(new webpack.HotModuleReplacementPlugin());
  }
  const pluginsToUse = isProd ? [...commonsPlugins, ...pluginsProduction] : commonsPlugins;
  return pluginsToUse;
};
const aliases = {
  moment$: "moment/moment",
  "react-loadable": "@7rulnik/react-loadable",
  // ... private aliases for modules
};

const webpackStatsProd = {
  children: true,
  chunks: false,
  chunkModules: false,
  chunkOrigins: false,
  optimizationBailout: true,
  source: false,
};

module.exports = function(env) {
  const isHot = (env && env.hot) || false;
  const isProd = (!isHot && (env && env.production)) || false;

  const pluginsToUse = getPlugins(isProd, isHot);

  return {
    cache: !isProd,
    devtool: false,
    mode: !isProd ? "development" : "production",
    stats: isProd ? webpackStatsProd : "minimal",
    entry: path.resolve(__dirname, "src", "check.ts"),
    output: {
      path: path.resolve(__dirname, "dist"),
      filename: isProd ? "[chunkhash].js" : "[name].bundle.js",
      chunkFilename: isProd ? "[chunkhash].chunk.js" : "[name].chunk.js",
      pathinfo: !isProd,
    },
    devServer: confHotReload,
    performance: {
      hints: isProd ? "warning" : false,
    },
    optimization: {
      splitChunks: { chunks: "all", cacheGroups: {} },
      sideEffects: false,
      minimize: isProd,
      minimizer: [
        new UglifyJsPlugin({
          uglifyOptions: {
            ecma: 7,
          },
          cache: false,
          parallel: true,
          sourceMap: false,
        }),
      ],
      runtimeChunk: false,
      concatenateModules: isProd,
    },
    resolve: {
      extensions: [".tsx", ".ts", ".jsx", ".js", ".json"],
      mainFields: ["module", "browser", "main"],
      alias: aliases,
      modules: [path.resolve(__dirname, "node_modules")],
    },
    target: "web",
    module: {
      rules: [
        {
          test: function(modulePath) {
            return (
              modulePath.endsWith(".ts") | modulePath.endsWith(".tsx") &&
              !(modulePath.endsWith("test.ts") | modulePath.endsWith("test.tsx"))
            );
          },
          use: [
            {
              loader: "babel-loader",
              options: {
                cacheDirectory: !isProd,
              },
            },
            "ts-loader",
          ],
          include: /src/,
          exclude: /node_modules/,
        },
        {
          test: /\.(js|jsx)$/,
          use: {
            loader: "babel-loader",
            options: {
              cacheDirectory: !isProd,
            },
          },
          include: /src/,
          exclude: /node_modules/,
        },
        {
          test: /\.css$/,
          use: [
            isHot ? { loader: "style-loader", options: { hmr: true } } : MiniCssExtractPlugin.loader,
            { loader: "css-loader", options: { minimize: isProd } },
            // {
            //   loader: "postcss-loader",
            //   options: {
            //     plugins: [autoprefixer],
            //   },
            // },
          ],
        },
        {
          test: /\.scss$/,
          use: [
            isHot ? { loader: "style-loader", options: { hmr: true } } : MiniCssExtractPlugin.loader,
            {
              loader: "typings-for-css-modules-loader",
              query: {
                modules: true,
                localIdentName: isProd ? "[hash:base64:10]" : "[name]__[local]",
                camelCase: false,
                namedExport: true,
                banner:
                  "// This file is automatically generated by typings-for-css-modules.\n// Please do not change this file!",
              },
            },
            {
              loader: "postcss-loader",
              options: {
                plugins: [autoprefixer],
              },
            },
            {
              loader: "sass-loader",
              query: {
                modules: true,
              },
            },
          ],
        },
        {
          test: /\.(jpe?g|png|gif|ogg|mp4|woff|woff2|ttf|eot)$/i,
          use: {
            loader: "file-loader",
            options: {
              name: "[name].[ext]",
              outputPath: "assets/",
            },
          },
        },
        {
          test: /\.svg/,
          use: [
            {
              loader: "file-loader",
              options: {
                name: "[name].[ext]",
                outputPath: "assets/",
              },
            },
            {
              loader: "svgo-loader",
              options: {
                plugins: [
                  { removeTitle: true },
                  { cleanupAttrs: true },
                  { removeComments: true },
                  { removeUnknownsAndDefaults: true },
                  { removeDesc: true },
                  { convertColors: { shorthex: false } },
                  { convertPathData: false },
                ],
              },
            },
          ],
        },
      ],
    },
    plugins: pluginsToUse,
  };
};

and the error I have

ℹ 「wdm」: Compiled successfully.
internal/stream_base_commons.js:59
  var err = req.handle.writev(req, chunks, allBuffers);
                       ^

TypeError: req.handle.writev is not a function
    at writevGeneric (internal/stream_base_commons.js:59:24)
    at Socket._writeGeneric (net.js:759:5)
    at Socket._writev (net.js:768:8)
    at doWrite (_stream_writable.js:408:12)
    at clearBuffer (_stream_writable.js:517:5)
    at Socket.Writable.uncork (_stream_writable.js:314:7)
    at connectionCorkNT (_http_outgoing.js:644:8)
    at process._tickCallback (internal/process/next_tick.js:63:19)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR!<[project]>@1.1.0 start: `DOMAIN_API=localhost:9000 webpack-dev-server --env.hot`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the <[project]>@1.1.0 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

Edit: Two of webpack dev server proxy path are used for Websocket connections to our backend launched in Docker locally, don't know if that might have an impact?

@addaleax
Copy link
Member

@YvanGuidoin Do you think you could work out a full reproduction based on this?

@YvanGuidoin
Copy link

@addaleax Tried to recreate a cleaned reproduction, but it isn't happening wihout the backend, and tried to recreate it with clean code (create-react-app) and a websocket server it's not happening either (even when calling 9/10 websocket in parallel per browser) ><

@addaleax
Copy link
Member

@YvanGuidoin Can you provide other information about the issue? Maybe you could attach the inspector to the Node process and see what the actual values of req.handle/req.handle.writev are?

@YvanGuidoin
Copy link

@addaleax yes I can, and if you have the time we can look at it together on our actual code, I haven't dwelled into the node inspector for now, so maybe your insight would make it faster.

I just tested and it seems to be fired almost each time, I know where to put the debugger to have the req values, but it is a circular structure so I can't get you a JSON of it.

@addaleax
Copy link
Member

@YvanGuidoin Hm, okay … maybe, alternatively, do you think you could patch Node.js yourself do to some debugging? E.g. add if (typeof req.handle.writev !== 'function') console.log(req.handle) before the offending line?

@karneaud
Copy link

+1 for this error as well below is a link I had posted to stack

https://stackoverflow.com/questions/51567590/req-handle-writev-is-not-a-function

thought it was something I was doing wrong with React.

@addaleax
Copy link
Member

Has anyone been able to come up with a reproduction that does not require access to an iOS simulator?

Has anyone tried to raise this issue at https://github.com/webpack/webpack-dev-server, since it only seems to affect this one particular CLI application?

Does anybody have more information than a stack trace (e.g. inspected the crash with chrome devtools)?

@karneaud
Copy link

@addaleax sorry but I could not provide a reproduction project because its really sporadic.

@Jessidhia
Copy link
Author

Jessidhia commented Jul 30, 2018

It looks like the constructor for the req.handle that is attempted to have writev called on it is made by the spdy package; the last "user code" instruction that runs before it's all internal is proxyRes.pipe(res) (normal piping from a read into a write socket).

Were there maybe any breaking changes made in 10.6.0 that could have broken spdy? This crash also happens in 10.7.0, but not in 10.5.0.

@Jessidhia
Copy link
Author

Looks like it has been known it would be broken soon because of it using node internals; it just wasn't expected to break in Node 10.

spdy-http2/node-spdy#333

@addaleax
Copy link
Member

@Kovensky Ah! Thanks for digging that up. I think this might be the relevant change: 64a3fad#diff-e6ef024c3775d787c38487a6309e491dL215

It’s easy enough to undo, but I’m a bit torn on whether we should. The spdy package is effectively unmaintained and, more importantly, could break again at any time due to its extremely fragile implementation – we even haven’t been able to test it in Node’s CI infastructure anymore because of this for a while. Acting as if what spdy does is supported behaviour is somewhat reckless, imo.

I’d prefer to look into adding support for the built-in HTTP/2 module for webpack-dev-server and/or disabling spdy in it for Node 10 – the latter is easy, and the former shouldn’t be too hard, and make both our and their lives a bit easier…

@Jessidhia
Copy link
Author

It also looks like webpack-dev-server (or anything using express) can't easily be migrated due to expressjs/express#3388 🤔

addaleax added a commit to addaleax/webpack-dev-server that referenced this issue Aug 1, 2018
`spdy` is effectively unmaintained, and as a consequence of an
implementation that extensively relies on Node’s non-public APIs, broken
on Node 10 and above. In those cases, only https will be used for now.
Once express supports Node's built-in HTTP/2 support, migrating over to
that should be the best way to go.

Fixes: webpack#1449
Fixes: nodejs/node#21665
addaleax added a commit to addaleax/webpack-dev-server that referenced this issue Aug 1, 2018
`spdy` is effectively unmaintained, and as a consequence of an
implementation that extensively relies on Node’s non-public APIs, broken
on Node 10 and above. In those cases, only https will be used for now.
Once express supports Node's built-in HTTP/2 support, migrating over to
that should be the best way to go.

Fixes: webpack#1449
Fixes: nodejs/node#21665
@addaleax
Copy link
Member

addaleax commented Aug 1, 2018

Opened a PR for webpack-dev-server to move away from spdy @ webpack/webpack-dev-server#1451.

Edit: If somebody wants to try that PR out in the "real" world, here’s how: https://github.com/webpack/webpack-dev-server/blob/master/CONTRIBUTING.md#testing-a-pull-request

addaleax added a commit to addaleax/webpack-dev-server that referenced this issue Aug 1, 2018
`spdy` is effectively unmaintained, and as a consequence of an
implementation that extensively relies on Node’s non-public APIs, broken
on Node 10 and above. In those cases, only https will be used for now.
Once express supports Node's built-in HTTP/2 support, migrating over to
that should be the best way to go.

Fixes: webpack#1449
Fixes: nodejs/node#21665
gaearon pushed a commit to facebook/create-react-app that referenced this issue Sep 2, 2018
This fixes the functionality of this dependency for Node 10 and above.

Refs: webpack/webpack-dev-server#1451
Refs: nodejs/node#21665
@addaleax
Copy link
Member

addaleax commented Sep 2, 2018

@lundibundi Thanks for the pointer, I didn’t realize all those downloads were coming from create-react-app :)

With that updated, I think this issue can be closed. If anybody runs into trouble – please try updating your dependencies first! :)

@addaleax addaleax closed this as completed Sep 2, 2018
prichodko pushed a commit to prichodko/create-react-app that referenced this issue Sep 9, 2018
This fixes the functionality of this dependency for Node 10 and above.

Refs: webpack/webpack-dev-server#1451
Refs: nodejs/node#21665
zmitry pushed a commit to zmitry/create-react-app that referenced this issue Sep 30, 2018
This fixes the functionality of this dependency for Node 10 and above.

Refs: webpack/webpack-dev-server#1451
Refs: nodejs/node#21665
RohanBhanderi pushed a commit to RohanBhanderi/webpack-dev-server that referenced this issue Oct 31, 2018
`spdy` is effectively unmaintained, and as a consequence of an
implementation that extensively relies on Node’s non-public APIs, broken
on Node 10 and above. In those cases, only https will be used for now.
Once express supports Node's built-in HTTP/2 support, migrating over to
that should be the best way to go.

related issues:
nodejs/node#21665
nodejs/node#21665
webpack#1449
expressjs/express#3388
RohanBhanderi pushed a commit to RohanBhanderi/webpack-dev-server that referenced this issue Oct 31, 2018
cherry pick of webpack@e97d345

`spdy` is effectively unmaintained, and as a consequence of an
implementation that extensively relies on Node’s non-public APIs, broken
on Node 10 and above. In those cases, only https will be used for now.
Once express supports Node's built-in HTTP/2 support, migrating over to
that should be the best way to go.

related issues:
nodejs/node#21665
nodejs/node#21665
webpack#1449
expressjs/express#3388
RohanBhanderi pushed a commit to RohanBhanderi/webpack-dev-server that referenced this issue Oct 31, 2018
cherry pick of webpack@e97d345

This commit is in webpack-dev-server v3 line, which requires webpack to be
upgraded to >= 4.0.0

`spdy` is effectively unmaintained, and as a consequence of an
implementation that extensively relies on Node’s non-public APIs, broken
on Node 10 and above. In those cases, only https will be used for now.
Once express supports Node's built-in HTTP/2 support, migrating over to
that should be the best way to go.

related issues:
nodejs/node#21665
nodejs/node#21665
webpack#1449
expressjs/express#3388
RohanBhanderi pushed a commit to RohanBhanderi/webpack-dev-server that referenced this issue Oct 31, 2018
cherry pick of webpack@e97d345

this issue was fixed is in webpack-dev-server v3 line, which requires webpack to be
upgraded to >= 4.0.0. This commit cherry picks the fix to v2 branch (on top of v2.11.3)
which does not require webpack to be upgraded to 4.0.0

`spdy` is effectively unmaintained, and as a consequence of an
implementation that extensively relies on Node’s non-public APIs, broken
on Node 10 and above. In those cases, only https will be used for now.
Once express supports Node's built-in HTTP/2 support, migrating over to
that should be the best way to go.

related issues:
nodejs/node#21665
nodejs/node#21665
webpack#1449
expressjs/express#3388
RohanBhanderi pushed a commit to RohanBhanderi/webpack-dev-server that referenced this issue Oct 31, 2018
Ports fix for webpack#1449 to v2 branch
cherry pick of webpack@e97d345

this issue was fixed in webpack-dev-server v3 line, which requires webpack to be
upgraded to >= 4.0.0. This commit cherry picks the fix to v2 branch (on top of v2.11.3)
which does not require webpack to be upgraded to 4.0.0

`spdy` is effectively unmaintained, and as a consequence of an
implementation that extensively relies on Node’s non-public APIs, broken
on Node 10 and above. In those cases, only https will be used for now.
Once express supports Node's built-in HTTP/2 support, migrating over to
that should be the best way to go.

related issues:
nodejs/node#21665
nodejs/node#21665
webpack#1449
expressjs/express#3388
RohanBhanderi pushed a commit to RohanBhanderi/webpack-dev-server that referenced this issue Nov 1, 2018
Ports fix for webpack#1449 to v2 branch
cherry pick of webpack@e97d345

this issue was fixed in webpack-dev-server v3 line, which requires webpack to be
upgraded to >= 4.0.0. This commit cherry picks the fix to v2 branch (on top of v2.11.3)
which does not require webpack to be upgraded to 4.0.0

`spdy` is effectively unmaintained, and as a consequence of an
implementation that extensively relies on Node’s non-public APIs, broken
on Node 10 and above. In those cases, only https will be used for now.
Once express supports Node's built-in HTTP/2 support, migrating over to
that should be the best way to go.

related issues:
nodejs/node#21665
nodejs/node#21665
webpack#1449
expressjs/express#3388
RohanBhanderi pushed a commit to RohanBhanderi/webpack-dev-server that referenced this issue Nov 1, 2018
Ports fix for webpack#1449 to v2 branch
cherry pick of webpack@e97d345

this issue was fixed in webpack-dev-server v3 line, which requires webpack to be
upgraded to >= 4.0.0. This commit cherry picks the fix to v2 branch (on top of v2.11.3)
which does not require webpack to be upgraded to 4.0.0

`spdy` is effectively unmaintained, and as a consequence of an
implementation that extensively relies on Node’s non-public APIs, broken
on Node 10 and above. In those cases, only https will be used for now.
Once express supports Node's built-in HTTP/2 support, migrating over to
that should be the best way to go.

related issues:
nodejs/node#21665
nodejs/node#21665
webpack#1449
expressjs/express#3388
RohanBhanderi pushed a commit to RohanBhanderi/webpack-dev-server that referenced this issue Nov 1, 2018
Ports fix for webpack#1449 to v2 branch
cherry pick of webpack@e97d345

this issue was fixed in webpack-dev-server v3 line, which requires webpack to be
upgraded to >= 4.0.0. This commit cherry picks the fix to v2 branch (on top of v2.11.3)
which does not require webpack to be upgraded to 4.0.0

`spdy` is effectively unmaintained, and as a consequence of an
implementation that extensively relies on Node’s non-public APIs, broken
on Node 10 and above. In those cases, only https will be used for now.
Once express supports Node's built-in HTTP/2 support, migrating over to
that should be the best way to go.

related issues:
nodejs/node#21665
nodejs/node#21665
webpack#1449
expressjs/express#3388
RohanBhanderi pushed a commit to RohanBhanderi/webpack-dev-server that referenced this issue Nov 1, 2018
Ports fix for webpack#1449 to v2 branch
cherry pick of webpack@e97d345

this issue was fixed in webpack-dev-server v3 line, which requires webpack to be
upgraded to >= 4.0.0. This commit cherry picks the fix to v2 branch (on top of v2.11.3)
which does not require webpack to be upgraded to 4.0.0

`spdy` is effectively unmaintained, and as a consequence of an
implementation that extensively relies on Node’s non-public APIs, broken
on Node 10 and above. In those cases, only https will be used for now.
Once express supports Node's built-in HTTP/2 support, migrating over to
that should be the best way to go.

related issues:
nodejs/node#21665
nodejs/node#21665
webpack#1449
expressjs/express#3388
ebenoist added a commit to reverbdotcom/webpack-dev-server that referenced this issue Nov 20, 2018
Do not use `spdy` on Node 10

`spdy` is effectively unmaintained, and as a consequence of an
implementation that extensively relies on Node’s non-public APIs, broken
on Node 10 and above. In those cases, only https will be used for now.
Once express supports Node's built-in HTTP/2 support, migrating over to
that should be the best way to go.

Fixes: webpack#1449
Fixes: nodejs/node#21665

https://github.com/webpack/webpack-dev-server/commit/e97d345ac370095a6e339b7997b939c88ef3e81b.patch
@rmatrose
Copy link

I was getting this error on Windows 10 x64 on NodeJS version 10.13.0. I simply removed NodeJS version 10.13.0 and installed version 8.11.3 and restarted my machine and it was gone!

@nicholas-eden
Copy link

Is there a fix or a workaround for this that doesn't require using node 8?

Using node 10.10 and angular 5 I get this error when I run the angular serve command. It only occurs when using the iOS simulator. It may have something to do with which version I'm emulating, definitely happens on iPad 9.2. I don't recall if it occurs in 12, or if I just haven't had it running long enough to trigger the error.

@addaleax
Copy link
Member

addaleax commented Mar 5, 2019

@nicholas-eden spdy-http2/handle-thing#5 should have fixed this on the spdy side, so updating your dependencies might help.

Otherwise, you may need to provide steps to reproduce in order for people to be able to help you.

@nicholas-eden
Copy link

nicholas-eden commented Mar 11, 2019

I don't know how reproducible this is on other projects, but here's what's happening:

  • Start the node server using ng serve
  • Access via chrome to verify it's up
  • Bring up an iPad 12 instance on Simulator
  • Open the page on https on the iPad instance

Strangely, this doesn't happen with an iPad 9 or 10 instance.

This is my error log:

TypeError: req.handle.writev is not a function
    at writevGeneric (internal/stream_base_commons.js:62:24)
    at Socket._writeGeneric (net.js:711:5)
    at Socket._writev (net.js:720:8)
    at doWrite (_stream_writable.js:408:12)
    at clearBuffer (_stream_writable.js:517:5)
    at Socket.Writable.uncork (_stream_writable.js:314:7)
    at connectionCorkNT (_http_outgoing.js:641:8)
    at process._tickCallback (internal/process/next_tick.js:63:19)
child_process.js:651
    throw err;
    ^

@boxfox619
Copy link

boxfox619 commented Mar 18, 2019

I have same problem when open page on https with IPhone X.
node version 10.6.0 -> occur 'req.writev is not a function' error
But, It worked fine on a desktop browser.

And i solved this problem with change node version to 8.11.3

  • webpack-dev-server version : 3.2.1

@martinKindall
Copy link

Same issue here
Ubuntu 16.04 64 bits
nodejs v10.15.0

Using create-react-script and it crashes when I use chrome on my cellphone. Chrome on my desktop doesn't produce this failure.

internal/stream_base_commons.js:62
var err = req.handle.writev(req, chunks, allBuffers);
^

TypeError: req.handle.writev is not a function
at writevGeneric (internal/stream_base_commons.js:62:24)
at Socket._writeGeneric (net.js:715:5)
at Socket._writev (net.js:724:8)
at doWrite (_stream_writable.js:408:12)
at clearBuffer (_stream_writable.js:517:5)
at Socket.Writable.uncork (_stream_writable.js:314:7)
at connectionCorkNT (_http_outgoing.js:641:8)
at process._tickCallback (internal/process/next_tick.js:63:19)

@alcmontejo
Copy link

what is the resolution?

@lundibundi
Copy link
Member

The resolution is to use webpack-dev-server of version >= 3.1.7 that fixed the bug.
Based on github milestones in create-react-app it should be shipped with the updated version starting with create-react-app@2.0+ (PR facebook/create-react-app#5032)

eagerdev12 added a commit to eagerdev12/creating-app that referenced this issue Dec 27, 2021
This fixes the functionality of this dependency for Node 10 and above.

Refs: webpack/webpack-dev-server#1451
Refs: nodejs/node#21665
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
net Issues and PRs related to the net subsystem.
Projects
None yet
Development

No branches or pull requests