During the update, we add warnings that we truncated. During the final my_ok call, we try to set the message to number of mods etc. This causes an assertion that a message is already set.

The problem is that we think we should error on warnings (strict), but we don't. The strict causes the final message to be an error about truncation. Then we try to add the normal update final message – assertion. (Do we actually do the update? Need to look into that.) Also, we don't seem to pay attention to the keyword IGNORE in the query, which causes InnoDB to not error, but issue warnings.

Upon range warning, we set thd->abort_on_warning to true. Theoretically, this was supposed to stop the problem from happening. It doesn't do what we want.

We need to return the error code from doUpdateDelete() which in turn sends it on th handler. Without a return code, handler isn't smart enough to know there was an error.

QA: This only breaks immediately for debug builds. Release builds may or may not ever show symptoms. To test, just attempt to update a char(8) field (longer doesn't break) with a string > 8 bytes.

Build verified: 1.4.3-1 source

server commit 90fb6f56db926337d1dd900a9f87c7db9e37a566
engine commit 5efa6a4dc52129be2de49fdfc23e44020401b86b

Non-debug does not have the issue.
There is no debug build for 1.4.2-1 for reproducing the issue and I am not able to build it from source.
Verified that the issue is not happening in 1.4.3-1 debug build.

Build verified: 1.5.0-1 source

server
commit 57950ded281731263f6aa358d43c7b9d51f3dbfb
engine
commit 46f30be5561f65eec488d61e011b727ca358720b