mysql
mysql copied to clipboard
mysqljs
NodeJs API + Webpack 2 Production Builds = Error: Received packet in the wrong sequence
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
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.
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
I haven't used webpack, and really have no idea why it would be broken when using it...
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
Let me clarify, I know you can write in ES6 without web pack, but it allowed for the transition to be a bit smoother....
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
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.
@jgrauel @dtslvr
Same question as above, do you find a way to solve it with mangle: true ?
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
},
})
],
}
};
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 :(
@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"
},
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().
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?
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(),
],
};
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 https://github.com/mysqljs/mysql/pull/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.
