Drop prepared statements for cached queries if connection gets swapped due to operations like ZDP
Cloud database providers like AWS Aurora offer Zero Downtime Patching (ZDP), which maintains connection availability during maintenance windows. However, ZDP has a critical limitation: prepared statements don't survive the underlying connection replacement that occurs during the patch process. This creates a mismatch between the client-side cache (node-mysql2's LRU cache of prepared statements) and the server-side reality. The client believes cached prepared statements are still valid, but the database has discarded them after the ZDP operation. When the application attempts to execute a cached prepared statement, it receives a "prepared statement not found" error.
Proposed Solution Implement resilient prepared statement handling that can recover from ZDP scenarios:
- Error Detection: Catch prepared statement errors that indicate the statement no longer exists on the server
- Cache Invalidation: Remove the invalid entry from the LRU cache
- Transparent Recovery: Automatically re-prepare the statement and retry the original query
- Seamless Experience: Handle this recovery transparently so the application layer doesn't need to manage ZDP-related failures
This approach would make the prepared statement cache self-healing, automatically adapting when cloud infrastructure operations invalidate server-side prepared statements while maintaining client-side cache consistency.
The key insight is treating prepared statement "not found" errors as cache invalidation signals rather than terminal failures, enabling graceful recovery from infrastructure-level operations like ZDP.