[MDEV-28611] Clarify difference between ER_CONNECTION_KILLED (1927) and error 2013 Created: 2022-05-18  Updated: 2023-04-27

Status: Confirmed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.2, 10.3, 10.4, 10.5, 10.6, 10.7, 10.8
Fix Version/s: 10.4, 10.5, 10.6

Type: Bug Priority: Major
Reporter: Daniel Lenski Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

While writing MTR tests of procedure code, it's sometimes necessary to expect the current connection/thread to be killed.

I've been using the following in my MTR .test files:

--error ER_CONNECTION_KILLED
 
call PROCEDURE_THAT_WILL_CAUSE_THIS_CONNECTION_TO_DIE();

However, this occasionally results in tests failing 

mysqltest: At line X, PROCEDURE_THAT_WILL_CAUSE_THIS_CONNECTION_TO_DIE() failed with wrong errno 2013: 'Lost connection to MySQL server during query', instead of 1927...

It would be useful to have clarity on when/why an MTR test can sometimes fail with error 2013 instead of error 1927/ER_CONNECTION_FAILED.

  • Is this a consequence of server- vs client-side timing of when the lost connection is detected?
  • Is there a way to ensure we consistently get only one result, and not the other?
  • If the variation is truly unavoidable, shouldn't all tests with --error ER_CONNECTION_KILLED also allow for --error 2013?

 Comments   
Comment by Daniel Lenski [ 2022-05-18 ]

MDEV-25802 has another example of a test that requires --error 2013, ER_CONNECTION_KILLED

Comment by Sergei Golubchik [ 2022-06-09 ] 

include/errmsg.h:#define CR_SERVER_LOST         2013

Comment by Sergei Golubchik [ 2022-06-09 ]

1927 (ER_CONNECTION_KILLED) is the server error code. A client can get it in the error packet.
2013 (CR_SERVER_LOST) is the client error. C API functions return it when they get an error reading or sending data, I suppose (didn't check).

I believe mysqltest does not know about client error names, so one cannot write

--error CR_SERVER_LOST

and has to use the numeric error code.

Why you can get either? Perhaps, if the server sends error 1927 and closes the connection, the result depends on whether the client manages to read the error packet before the connection is closed.

Comment by Daniel Lenski [ 2022-06-09 ]

serg wrote:

1927 (ER_CONNECTION_KILLED) is the server error code. A client can get it in the error packet.
2013 (CR_SERVER_LOST) is the client error. C API functions return it when they get an error reading or sending data, I suppose (didn't check).

Yes, understood.

Why you can get either? Perhaps, if the server sends error 1927 and closes the connection, the result depends on whether the client manages to read the error packet before the connection is closed.

Yes, I think this is right. It's basically a race condition. What I'm emphasizing here is that this makes it difficult to write a correct test… or a correct exception handler in any application that uses a MariaDB connector library, for that matter.

If the test can randomly get either of these errors (seems to be about 90% 1927 and 10% 2013 in my case), then if you write it to only catch one of them, the test will randomly fail.

Can MTR or the C API be improved so that these errors are combined?

Comment by Sergei Golubchik [ 2022-06-28 ]

Yes, you're right. If my explanation is correct, then it's a bug, of course, the error should not depend on how fast host OS closes connections. And it should be fixed in the Connector/C, clients shouldn't have to write

if (error == ER_CONNECTION_KILLED || error == CR_SERVER_LOST)

Generated at Thu Feb 08 10:02:06 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.