Bug Description
When using mysql2.createPoolCluster (or createPool) with valid pool-level options such as acquireTimeout, the library emits a warning indicating that the option is invalid for the Connection.
While acquireTimeout is a valid and necessary option for the Pool behavior, it seems the Pool implementation passes the entire configuration object down to the underlying Connection constructor without filtering out pool-specific keys. Since Connection now performs stricter validation (checking against a whitelist of known connection options), it flags acquireTimeout as invalid.
This creates a contradiction where a user provides a valid Pool configuration but receives warnings (which state they will become errors in future versions) because the underlying Connection doesn't recognize those Pool-specific settings.
Reproducible Example
const mysql = require('mysql2');
// Creating a pool cluster with valid pool options
const pool = mysql.createPoolCluster();
pool.add('MASTER', {
host: 'localhost',
user: 'root',
database: 'test',
// acquireTimeout is a valid Pool option (default 10000)
// But passing it explicitly triggers the warning
acquireTimeout: 10000
});
pool.getConnection('MASTER', (err, connection) => {
if (err) console.error(err);
else {
console.log('Connected!');
connection.release();
}
pool.end();
});
Observed Behavior
The console outputs the following warning:
Ignoring invalid configuration option passed to Connection: acquireTimeout. This is currently a warning, but in future versions of MySQL2, an error will be thrown if you pass an invalid configuration option to a Connection
Expected Behavior
Pool-specific options like acquireTimeout, connectionLimit, queueLimit, etc., should be consumed by the Pool and not passed down (or should be filtered out) when creating a new Connection instance. Alternatively, the Connection validator should allow/ignore known Pool options without emitting a warning.
Environment
- Node.js Version: 20.x
- MySQL2 Version: 3.10+
- Operating System: macOS / Linux
Bug Description
When using
mysql2.createPoolCluster(orcreatePool) with valid pool-level options such asacquireTimeout, the library emits a warning indicating that the option is invalid for theConnection.While
acquireTimeoutis a valid and necessary option for the Pool behavior, it seems the Pool implementation passes the entire configuration object down to the underlyingConnectionconstructor without filtering out pool-specific keys. SinceConnectionnow performs stricter validation (checking against a whitelist of known connection options), it flagsacquireTimeoutas invalid.This creates a contradiction where a user provides a valid Pool configuration but receives warnings (which state they will become errors in future versions) because the underlying Connection doesn't recognize those Pool-specific settings.
Reproducible Example
Observed Behavior
The console outputs the following warning:
Expected Behavior
Pool-specific options like
acquireTimeout,connectionLimit,queueLimit, etc., should be consumed by the Pool and not passed down (or should be filtered out) when creating a newConnectioninstance. Alternatively, theConnectionvalidator should allow/ignore known Pool options without emitting a warning.Environment