Skip to content

Conversation

IsaacHorvath
Copy link
Contributor

After this discussion (#4587 ) in the spring, I decided to go ahead and build a MySQL cancel token according to the basic design discussed. I hope taking a stab at this and opening a PR right away isn't premature or inappropriate.

I added some basic documentation and a test, although the test is a bit awkward: MySQL wouldn't reliably return an error for me when a query was cancelled, so I had to fall back to using the load method and checking the return integer. Also, I wasn't able to move an AsyncMysqlConnection between threads so I had it send the cancel token via a channel.

Let me know if there are any changes I should make or if I'm out of line here.

@weiznich
Copy link
Owner

Thanks for opening this Pr. I just want to leave a message here to state that I've not forgotten about this. It's just a lot of other stuff currently ongoing so that I did not have the capacity to look at this in detail. Hopefully I'm able to do that in the next week or so.

@IsaacHorvath
Copy link
Contributor Author

No worries at all! No rush on my end. I implemented a downstream solution in my app involving a reaper on a separate thread that has access to a connection pool.

Speaking of which, it may be a good idea for me to add a second cancel_token method (or an enum parameter) to accept a connection pool from which it can request a connection, instead of firing up a new one. This would be an advantage when an app already has a pool, but could lead to undefined behaviour if the pool connection details do not match the existing query, so I would want to figure out a check for that.

@weiznich weiznich merged commit c339949 into weiznich:main Oct 2, 2025
24 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants