[OpenSIPS-Devel] [OpenSIPS/opensips] e40d21: db_mysql: recover from ER_UNKNOWN_STMT_HANDLER (12...

[Ravitez Dondeti]

  Branch: refs/heads/3.6
  Home:   https://github.com/OpenSIPS/opensips
  Commit: e40d21e7aad05540997c0def26ae8f6505abb9fa
      https://github.com/OpenSIPS/opensips/commit/e40d21e7aad05540997c0def26ae8f6505abb9fa
  Author: Ravitez Dondeti <dondetir at users.noreply.github.com>
  Date:   2026-04-17 (Fri, 17 Apr 2026)

  Changed paths:
    M modules/db_mysql/dbase.c

  Log Message:
  -----------
  db_mysql: recover from ER_UNKNOWN_STMT_HANDLER (1243) (#3865)

The prepared-statement execute wrapper treats MySQL error 1243
(ER_UNKNOWN_STMT_HANDLER) as a hard failure and skips the existing
reconnect + re-prepare path. This surfaces in production when the
backing database is replaced underneath a live client connection -
for example during an AWS Aurora zero-downtime minor-version upgrade,
which preserves the TCP connection but drops the server-side
prepared-statement cache. The next stmt_execute returns 1243, OpenSIPS
logs CRITICAL and the query fails instead of transparently recovering.

Add the case to wrapper_single_mysql_stmt_execute so it funnels into
the same switch_state_to_disconnected -> connect_with_retry ->
re_init_statement recovery path that already handles CR_SERVER_GONE_ERROR
and friends.

ER_NEED_REPREPARE (1615) is intentionally not added: libmysqlclient
auto-reprepare already handles that case. 1243 bypasses auto-reprepare
because the server has no record of the handle at all.

The companion prepare wrapper is not modified: it starts from a fresh
mysql_stmt_init() handle that carries no server-side ID, so the server
cannot return 1243 in response to a prepare request.

Reported-by: Sasmita Panda <spanda at 3clogic.com>
(cherry picked from commit 9453ee09412c3a49a664bccad21757311d419688)



To unsubscribe from these emails, change your notification settings at https://github.com/OpenSIPS/opensips/settings/notifications