NodeJs API + Webpack 2 Production Builds = Error: Received packet in the wrong sequence

[jgrauel]

Hey - I love this module, thanks. I would love to use it in a nodeJs Api we are building, however I am running into an {odd?} issue where I am unable to move my code into a production environment. Every time I compile with webpack without setting devtool="eval" causes any attempt to make a connection result in an Error: Received packet in the wrong sequence.
My understanding is the devtool option controls if and how Source maps are generated from the compile process. I am not sure why exactly this would effect the execution of code, no errors result from actual compiling. Would love to know if there is some setting I am missing or way to get this working. Thanks

[dougwilson]

There is a precious issue still open about this, but I'm not sure what the fix is. If you can PR a fix, I'll be happy to merge it.

[dougwilson]

• previous issue

[jgrauel]

I saw the previous issue but it mentioned the additional use of Electron? and i wanted to specifiy it was just webPack and the module straight way

[jgrauel]

I am honestly unclear where to begin to fix , so would welcome guidance :)

[dougwilson]

I haven't used webpack, and really have no idea why it would be broken when using it...

[sidorares]

@jgrauel what's the reason you need webpack in the first place?

[jgrauel]

First I started using it so I can write in ES6 and its nice to have the files packed up on the server. So I found out that the error only occurs IF the webpack.optimize.UglifyJsPlugin is used. So that is progress, you can package/minimize without the Uglify. And that gives us a point of where to look. I am looking up if it has to do with specific settings only

[jgrauel]

Let me clarify, I know you can write in ES6 without web pack, but it allowed for the transition to be a bit smoother....

[jgrauel]

I use it to compile the code for client side as well :)

[jgrauel]

From what I have learned so far, as long as you set the option of mangle:false, the uglify plugin will not cause the error in the code. This is using webpack 2.2

[thewillhuang]

do something like https://github.com/apex/apex/blob/master/_examples/babel-webpack2/webpack.config.babel.js I don't recommend mangling anything as that would change variable names in unexpected places.

[dtslvr]

@jgrauel Have you found a way to also use mangle: true in the meantime?

[wenisy]

@jgrauel @dtslvr
Same question as above, do you find a way to solve it with mangle: true ?

[ryantate13]

I was getting "Error: Received packet in the wrong sequence" too but now I have Webpack 4 bundling mysql correctly using the config below:

const UglifyJsPlugin = require('uglifyjs-webpack-plugin'); // comes bundled with Webpack 4

module.exports = {
    mode: 'production',
    target: 'node',
    optimization: {
        minimizer: [
            new UglifyJsPlugin({
                uglifyOptions: {
                    mangle: false
                },
            })
        ],
    }
};

[alexjurkiewicz]

This happens to me using the default minifier of Webpack 4: terser.

If you want to disable minimisation:

optimization: {
    minimize: false
  }

Hopefully this issue can be fixed soon! My bundle size is doubled :(

[rudijs]

@alexjurkiewicz I found this worked and kept my bundle much smaller than minimize: false

  optimization: {
    minimizer: [new TerserPlugin({ terserOptions: { mangle: false } })] // mangle false else mysql blow ups with "PROTOCOL_INCORRECT_PACKET_SEQUENCE"
  },

[Arlen22]

Here is a stack trace for this problem. The paths indicate where the source file was found when packaged.

Error: Received packet in the wrong sequence.
    at u._parsePacket (/node_modules/mysql/lib/protocol/Protocol.js:283:17)
    at u._onPacket [as _parsePacket] (/node_modules/mysql/lib/protocol/Parser.js:433:10)
    at u._parsePacket [as write] (/node_modules/mysql/lib/protocol/Parser.js:43:10)
    at u.write (/node_modules/mysql/lib/protocol/Protocol.js:38:16)
    at Socket.write (/node_modules/mysql/lib/Connection.js:91:28)
    at Socket.apply (/node_modules/mysql/lib/Connection.js:525:10)
    at Socket.emit (events.js:198:13)
    at Socket.EventEmitter.emit (domain.js:448:20)
    at addChunk (_stream_readable.js:288:12)
    at readableAddChunk (_stream_readable.js:269:11)
    --------------------
    at u._enqueue (/node_modules/mysql/lib/protocol/Protocol.js:144:48)
    at u._enqueue [as handshake] (/node_modules/mysql/lib/protocol/Protocol.js:51:23)
    at s.handshake [as connect] (/node_modules/mysql/lib/Connection.js:119:18)
    at connect [as getConnection] (/node_modules/mysql/lib/Pool.js:48:16)
    at pool.getConnection()

My pool is initialized like pool = createPool(config.mysql_config); and mysql_config doesn't specify anything special. The error happens on the first call to pool.getConnection().

[Arlen22]

Is something weird happening in this stack trace or is this a normal stack trace? It almost looks like somehow we've got a short-circuit happening. Is that what it looks like to you?

[ggriffin]

We're also seeing this. We use typescript and webpack to bundle packages for AWS Lambda. Not sure why the stack trace is "weird" for us as well.

Note: Object.executeSql is a wrapper function

Received packet in the wrong sequence.
    at p._parsePacket (/var/task/bundle.js:2:4415295)
    at p._parsePacket (/var/task/bundle.js:2:4424024)
    at p.write (/var/task/bundle.js:2:4418252)
    at p.write (/var/task/bundle.js:2:4411763)
    at Socket.<anonymous> (/var/task/bundle.js:1:52792)
    at Socket.<anonymous> (/var/task/bundle.js:1:51894)
    at Socket.emit (events.js:223:5)
    at Socket.EventEmitter.emit (domain.js:475:20)
    at addChunk (_stream_readable.js:309:12)
    at readableAddChunk (_stream_readable.js:290:11)
    --------------------
    at p._enqueue (/var/task/bundle.js:2:4413141)
    at p.handshake (/var/task/bundle.js:2:4411886)
    at l.connect (/var/task/bundle.js:1:53664)
    at l._implyConnect (/var/task/bundle.js:1:58369)
    at l.query (/var/task/bundle.js:1:54742)
    at /var/task/bundle.js:1:170563
    at new Promise (<anonymous>)
    at Object.executeSql (/var/task/bundle.js:1:170541)
    at Runtime.t.handler (/var/task/bundle.js:1:166558)
    at Runtime.handleOnce (/var/runtime/Runtime.js:66:25) {
  code: 'PROTOCOL_INCORRECT_PACKET_SEQUENCE',
  fatal: true

Current workaround is to disable minification in webpack.config.js:

  optimization: {
    minimize: false,
  },

We've tried calling query on both a Connection and a Pool using the following config:

const config: Mysql.ConnectionConfig = {
  host: Utils.checkEnvironmentVariable('MYSQL_HOST'),
  port: Number(Utils.checkEnvironmentVariable('MYSQL_PORT')),
  user: Utils.checkEnvironmentVariable('MYSQL_USERNAME'),
  password: Utils.checkEnvironmentVariable('MYSQL_PASSWORD'),
  multipleStatements: true,
};

webpack.config.js

const path = require('path');
const global = require('../../webpack.global');

module.exports = {
  ...global,
  optimization: {
    // Avoid "Error: Received packet in the wrong sequence."
    // See: https://github.com/mysqljs/mysql/issues/1655
    minimize: false,
  },
  entry: './src/index.ts',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist'),
    libraryTarget: 'commonjs',
  },
};

webpack.global

const TerserPlugin = require('terser-webpack-plugin');
const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');
const HardSourceWebpackPlugin = require('hard-source-webpack-plugin');

module.exports = {
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        exclude: [/node_modules/, /__tests__/, /__template__/],
        use: [
          {
            loader: 'ts-loader',
            options: {
              transpileOnly: true,
            },
          },
        ],
      },
    ],
  },
  target: 'node',
  mode: 'production',
  optimization: {
    minimize: true,
    minimizer: [
      new TerserPlugin({
        terserOptions: {
          exclude: [/node_modules/, /__tests__/, /__template__/],
          compress: {
            drop_console: false,
          },
          parallel: true,
          cache: true,
        },
      }),
    ],
  },
  resolve: {
    extensions: ['.tsx', '.ts', '.js'],
  },
  plugins: [
    new ForkTsCheckerWebpackPlugin({
      memoryLimit: 4096,
    }),
    new HardSourceWebpackPlugin(),
  ],
};

[lneves12]

this PR: #2375 might help with this

[NoxHarmonium]

Another workaround that avoids having to turn off minification altogether is to tell the Webpack TerserPlugin to avoid mangling important function names. I got the list of function names from #2375 and put them into the keep_fnames list

  optimization: {
    minimizer: [
      new TerserPlugin({
        cache: true,
        parallel: true,
        sourceMap: true,
        terserOptions: {
          // Preventing mangling of function names fixes "Received packet in the wrong sequence" bug
          // See https://github.com/mysqljs/mysql/issues/1655 and https://github.com/mysqljs/mysql/pull/2375/files
          keep_fnames: /Packet|ChangeUser|Handshake|Ping|Query|Quit|Sequence|Statistics/,
        },
      }),
    ],
  },

I'm not sure if all those functions need to be there but I thought it was safer to include them all.