trace: false is ignored by most promise-API methods, including per-query hot paths #4501

Summary

trace: false is only honoured by four of the promise-API entry points. Every other promise method still calls captureStackHolder(...) unconditionally, so the per-call Error.captureStackTrace cannot be opted out of. Three of the ungated call sites are per-query hot paths, not just lifecycle methods.

Current state on master

Gated (respect config.trace):

Not gated — per-query paths:

Not gated — lifecycle/per-connection:

The most user-visible consequence is PromisePreparedStatementInfo#execute: the documented way to reuse a prepared statement is const stmt = await conn.prepare(sql) followed by repeated stmt.execute(params), and that loop pays a stack capture per query with no way to turn it off. PoolCluster users are in the same position for every query they run.

Why it matters

Measured on the gated path, so it is a direct indication of what the ungated paths still pay. Workload: 8 concurrent pool.execute() of a single-row prepared query against MySQL 9.7.2 (local Docker), metric = client CPU microseconds per query, median of interleaved runs, fresh process each:

(Repeat runs put the node figure in the 11-15% band and bun in the 5-9% band.)

Suggested fix

Apply the same ternary already used at connection.js:33 to the remaining sites, reading config.trace (or config.connectionConfig.trace for pool/cluster, this.statement.connection.config.trace or similar for the prepared-statement wrapper). makeDoneCb / applyCapturedStack already handle stackHolder === undefined, so no other change is needed.

This stays backward compatible: ConnectionConfig sets this.trace = options.trace !== false, so only an explicit false opts out — unset, true, 0, null and undefined all keep today's behaviour.

Note on affected versions

Worth flagging for anyone reading this later: trace was parsed but never read anywhere in the library before 3.24.0 (in 3.16.3-3.23.0 the only references are the default and this.trace = options.trace !== false in connection_config.js). The promise wrapper captured unconditionally regardless of the setting. Gating was introduced in 3.24.0 for query/execute; this issue is about finishing that work.

Happy to send a PR if the approach looks right.