Hi! First of all, thanks for the great library.
We use Finch with pool_max_idle_time configured and we occasionally hit the race condition where a checkout happens right when the pool is terminating due to being idle. When that happens, the caller gets an exit instead of an {:error, exception} return: the catch :exit in Finch.HTTP1.Pool.request/6 only converts the checkout timeout case into a friendly error, and re-raises everything else with exit(data), so the pool shutdown exit propagates all the way up to the caller.
I know this was mentioned at the NimblePool level in dashbitco/nimble_pool#49, and the conclusion there was leaning towards NimblePool staying minimal and leaving safe termination to the clients. Which makes me wonder: if it's not going to be handled in NimblePool, would it make sense for Finch to handle it, since Finch is the one exposing pool_max_idle_time as a built-in feature?
I don't have a deep knowledge of the pool internals, so I might be missing reasons why this is deliberately not handled (maybe distinguishing the idle-shutdown exit from other legitimate exits is not reliable, or the transparent retry hides failures you'd rather surface?). Mostly I'd like to understand whether this is something you'd consider in Finch, or if the position is that users of pool_max_idle_time should handle this race themselves — and if so, what the recommended pattern would be.
Thanks!
Hi! First of all, thanks for the great library.
We use Finch with
pool_max_idle_timeconfigured and we occasionally hit the race condition where a checkout happens right when the pool is terminating due to being idle. When that happens, the caller gets an exit instead of an{:error, exception}return: thecatch :exitinFinch.HTTP1.Pool.request/6only converts the checkout timeout case into a friendly error, and re-raises everything else withexit(data), so the pool shutdown exit propagates all the way up to the caller.I know this was mentioned at the NimblePool level in dashbitco/nimble_pool#49, and the conclusion there was leaning towards NimblePool staying minimal and leaving safe termination to the clients. Which makes me wonder: if it's not going to be handled in NimblePool, would it make sense for Finch to handle it, since Finch is the one exposing
pool_max_idle_timeas a built-in feature?I don't have a deep knowledge of the pool internals, so I might be missing reasons why this is deliberately not handled (maybe distinguishing the idle-shutdown exit from other legitimate exits is not reliable, or the transparent retry hides failures you'd rather surface?). Mostly I'd like to understand whether this is something you'd consider in Finch, or if the position is that users of
pool_max_idle_timeshould handle this race themselves — and if so, what the recommended pattern would be.Thanks!