<p>ER_SIGNAL_WARN (code 1642) appears when a SIGNAL or RESIGNAL statement raises a user-defined warning that the calling code does not handle.</p>
<p>MySQL Error 1642: ER_SIGNAL_WARN happens when a stored routine raises a user-defined warning that is not caught or checked. Handle or clear the warning with GET DIAGNOSTICS or alter the SIGNAL level to NOTE to resolve the issue.</p>
Unhandled user-defined warning condition
Error 1642 indicates that a SIGNAL or RESIGNAL statement inside a stored procedure, trigger, or function issued a warning condition, but the surrounding code failed to process it. MySQL therefore propagates an unhandled warning to the client.
The message text Unhandled user-defined warning condition highlights that the condition name or SQLSTATE returned by SIGNAL reached the outermost scope without being read by GET DIAGNOSTICS or handled in application code.
The error appears while running stored routines that purposefully raise warnings to flag non-fatal business rules, such as data range checks or soft validations. It typically shows up during INSERT, UPDATE, or CALL statements that invoke those routines.
It can also surface in AFTER triggers firing on large batch operations when a SIGNAL WARNING runs for certain rows and no diagnostics processing follows.
Leaving ER_SIGNAL_WARN unhandled pollutes application logs, hides real issues behind repeated noise, and may block ORMs that treat any server warning as an error. Cleaning it up improves reliability and keeps the warning flow intentional.
Most cases stem from forgetting to add GET DIAGNOSTICS after SIGNAL, using an incorrect condition level, or calling legacy routines that still contain SIGNAL WARNING statements.
The error also arises when an application catches only errors but not warnings returned in the diagnostics area, letting the warning bubble up.
First locate the SIGNAL or RESIGNAL statement generating the warning by checking routine text or enabling the general log. Decide whether the situation should be a NOTE, WARNING, or ERROR.
If a warning is desired, follow the SIGNAL with GET DIAGNOSTICS to read and clear it, or handle it in the client layer. Alternatively change SIGNAL SQLSTATE to '00000' level NOTE to downgrade its severity.
Soft validation in a BEFORE INSERT trigger often uses SIGNAL SQLSTATE '01000'. Attach a GET DIAGNOSTICS immediately after to consume the message and avoid propagation.
Batch ETL scripts calling a stored procedure repeatedly may hit ER_SIGNAL_WARN. Move input checks to the application side or switch the procedure to RETURN status codes instead of SIGNAL.
- Always pair SIGNAL with GET DIAGNOSTICS when level WARNING is used inside routines.
- Prefer NOTE for purely informational messages.
- Document routine output expectations so application developers know to fetch diagnostics.
- Use Galaxy’s AI copilot to scan stored routine code and flag unhandled SIGNAL statements before deployment.
ER_SIGNAL_NOT_FOUND (1643) appears when a RESIGNAL references a nonexistent handler. ER_RESIGNAL_WITHOUT_ACTIVE_HANDLER (1645) fires if RESIGNAL is issued outside a handler. Both require correct handler context, unlike ER_SIGNAL_WARN which focuses on unhandled warnings.
The routine raises a warning but never retrieves it, so MySQL forwards it to the caller.
The developer used SIGNAL WARNING when a NOTE or ERROR was intended, leaving the caller unprepared.
Applications ignoring the diagnostics area let warnings propagate as unhandled.
Older stored procedures migrated to new schemas still contain SIGNAL WARNING statements without handlers.
Raised when RESIGNAL refers to an undefined condition - fix by defining a handler.
Occurs when RESIGNAL is executed outside an active handler block.
Often confused with ER_SIGNAL_WARN; this warning comes from implicit type conversion, not SIGNAL.
No, a warning does not roll back a transaction by default, but your application may treat any warning as a failure.
You cannot disable the error, but you can change SIGNAL statements to NOTE or fetch diagnostics to clear them.
Enable the general log or use SHOW WARNINGS immediately after the failing call to reveal the routine and line number.
Galaxy’s AI copilot inspects stored routine text, detects unhandled SIGNAL WARNING patterns, and suggests inline GET DIAGNOSTICS code snippets.