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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants