If asynchronous query calls fail to get a database object, "convert cache tables" maintenance operations fail silently

I'm testing out apdqc module in the integration environment for a Drupal Commerce-heavy site I'm working on as I expect it can resolve or at least mitigate some Rules locking issues we're having.

I've gotten configuration information into settings.php and resolved most of the red items in the status report except for the innodb_buffer_pool_size (which I intend to bother our sysadmins about later along with some of the yellow items). I converted semaphore table to memory, which worked fine. I then attempt the other two operations, converting cache table collations and indices. They both give a success message.... but don't go away. They're still there to be run, status report is still complaining about them.

Digging in and doing some brute force debugging on the collation one, I confirm that despite the success message, the cache table collations are not getting updated. Digging further, I discover that the async_query calls are failing (returning "NO DB" - digging even further, they're getting access denied when they try to make a database connection - I need to debug that further myself, will put in a bug report if I find an issue on apdqc's side.) But the convert cache table operations don't check for this condition, and assume all went well.

It would be nice if these operations reported when this sort of thing goes wrong with the async_query (to surface whatever configuration issue and/or bug is at play here) and/or fell back to db_query for this case. Failing silently while returning a success message is somewhat less than desirable. (Some sort of status report test for async_query might be nice too, but I'll perhaps address that in a separate ticket after I figure out what's going wrong in our particular case.)