fix: switch from prepared statements to text protocol to prevent stat…#250
Open
fix: switch from prepared statements to text protocol to prevent stat…#250
Conversation
…ement leak Replace all CONNECTION.execute() calls with CONNECTION.query() in db.js to use MySQL text protocol instead of prepared statements. This prevents the server from accumulating prepared statements that exceed max_prepared_stmt_count (16382), especially for dynamic queries with varying field names. Also adds maxPreparedStatements safety net in pool config.
query() escapes JS objects as SQL SET-clauses instead of JSON strings, breaking INSERT/UPDATE. Wrap document with JSON.stringify() in put() and update() to serialize correctly.
charlypa
force-pushed
the
fix/prepared-statement-leak
branch
from
377e05a to
0e630b0
Compare
Revert the execute→query migration (473d82e) and the JSON.stringify workaround (0e630b0). The prepared statement leak is properly fixed by setting maxPreparedStatements=200 per connection, which keeps the server-side total well under max_prepared_stmt_count (16382) while leveraging mysql2's built-in LRU cache for automatic deallocation.
charlypa
force-pushed
the
fix/prepared-statement-leak
branch
from
853e267 to
5f0b6a6
Compare
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix: Revert to
execute()with safemaxPreparedStatementslimitSummary
execute()toquery()migration and theJSON.stringify()workaround — both were unnecessarymaxPreparedStatements = 200per connection, leveraging mysql2's built-in LRU cache for automatic deallocationProblem
The prepared statement leak was caused by mysql2's default
maxPreparedStatementsof 16,000 per connection. With a pool of 10 connections, that allows up to 160,000 server-side prepared statements — far exceeding MySQL's globalmax_prepared_stmt_count(16,382).The previous fix switched all
execute()calls toquery()(text protocol), which avoided prepared statements entirely but introduced a side-effect: object parameters were no longer auto-serialized, requiringJSON.stringify()workarounds input()andupdate().Solution
mysql2 already has a built-in LRU cache that automatically calls
statement.close()(sendsCOM_STMT_CLOSE) when the cache is full. Soexecute()is safe — we just need a conservativemaxPreparedStatementsper connection.With
connectionLimit = 10andmaxPreparedStatements = 200, the max server-side total is 2,000 — well under the 16,382 limit.Changes
src/utils/db.jsquery()calls back toexecute()src/utils/db.jsJSON.stringify()workarounds fromput()andupdate()src/utils/db.jsmaxPreparedStatements = 200in pool configtest/unit/setup-mocks.jsqueryback toexecutetest/unit/utils/db-test.spec.jsexecutetest/unit/utils/db-security-test.spec.jsexecutetest/unit/utils/list-apis-test.spec.jsexecuteTest plan