Can reproduce this. I had to adjust the test case to use

$c->query('SET max_execution_time=1');
$c->query('SELECT SLEEP(10) UNION ALL SELECT 1', MYSQLI_ASYNC|MYSQLI_USE_RESULT);

because my MySQL version doesn't support max_statement_time, and seems to immediately return from SLEEP without the UNION ALL.

After looking a bit closer, I don't think this is a bug. With STORE_RESULT, the response is processed at that point, so any errors will be encountered there. With USE_RESULT, it will happen when actually reading from the result sets, so you need to be prepared for errors to occur at that point.

This doesn't have anything to do with async, the behavior is the same if you do:

$c->query('SET max_execution_time=1');
$result = $c->query('SELECT SLEEP(10) UNION ALL SELECT 1', MYSQLI_USE_RESULT); 
var_dump($result->fetch_row());

It will throw on the fetch_row(), not the query().

> For other queries with bad syntax or that reference non-existent columns/tables, the connection handle error status is updated when reap_async_query() is called, but not when the query gets killed.

This is also expected. Syntax errors are detected when the query is initially submitted, while the timeout occurs only after the query has successfully started execution.

I'd like a second opinion from @dharman to confirm that the current behavior is correct.

I can't reproduce the behaviour with MariaDB, but I can reproduce it with MySQL 8 and the code provided by Nikita. 

To summarize the issue: You expect reap_async_query to throw an error when the execution time of the SELECT query exceeds the limit. The actual behaviour is that the error is thrown by the fetch_row statement. 

This is not a bug, this is a feature. Time out errors in contrast to syntax errors are not triggered by the SQL being incorrect. They are triggered by MySQL when the result set preparation goes wrong. There's a small number of things that can produce errors when preparing the result set, but nonetheless, they happen and you need to be prepared that reading the result set can fail at any point. 

The difference between MYSQLI_USE_RESULT and MYSQLI_STORE_RESULT is that MYSQLI_STORE_RESULT will read all result set rows as soon as the query is executed (it internally fetches the whole result row by row). When using MYSQLI_USE_RESULT you have to ask PHP to read every single row from the MySQL server row by row yourself; the result isn't read in advance. In the example you shared, the query execution does not produce errors, but result set preparation does. This means that whenever PHP attempts to read the first row, it will get an error instead of the actual row. 

The behaviour can be better understood when you consider the timeout on the second row instead. 

$c->query('SET max_execution_time=200');
$c->query('VALUES ROW(1,-2), ROW(5,SLEEP(10)) UNION ALL SELECT 3,100', MYSQLI_ASYNC | MYSQLI_USE_RESULT);

This will produce an error only after the second fetch_row() call. Preparation of the first row will not take more than 200ms, but the second row takes over 10000ms so it will time out and throw an error. If you use STORE mode, PHP would try to read all rows at once, but fail and return an error. If you use USE mode, you can at least read the first row and get the error when trying to read the second row. 

This is a feature because it allows you to read partial result sets when the execution times out.