Dangling transactions when pooled connections dropped about diesel_async HOT 4 CLOSED

Thanks for opening this issue. I must admit that I thought that part of code was already in place, so it seems like I just missed to do that. Which means I would definitely accept a PR for that, although I would rather change the default is_broken() implementation to do that for all connection implementations.

I'm also interested in other more targeted solutions for this, but I've failed to find something yet that's not coupled to a specific runtime or that would possibly block on drop or swallow errors. I think the postgres approach needs access to the underlying runtime to work. I'm also not user how they handle errors there or guarantee that it happens "fast" after dropping the future (which is somewhat important, so that the relevant future is not open for that long).

from diesel_async.

Turns out there was an existing function which checks for this and was just not hooked up - will push through a PR.

from diesel_async.

Solving it in a generic way does seem tricky. One possible idea for a DB-neutral solution would be a newtype that wraps the various pool implementations, and stores a vec of connections needing cleanup. Each time pool.get() is called, it could use that async context to clean up any of those objects, so if the pool is used with reasonable frequency, the objects in a bad state shouldn't stick around for long. I think deadpool provides a way to take a connection out of the pool, but don't know about bb8 or mobc, and it would add some extra complexity.

from diesel_async.

(sorry, meant to close+re-open the PR to re-run the tests)

from diesel_async.