gen_server mailbox bloat impact on connection pool availability

In Erlang/OTP, using a `gen_server` to manage connection pools can lead to intermittent exhaustion when downstream dependencies experience latency. While the process remains active, the `gen_server` loop lacks a native timeout for individual message processing. If a request handler blocks on external I/O, the process cannot consume subsequent messages, causing the mailbox to grow.

This behavior often results in 'mailbox bloat,' where the pool appears exhausted because the manager process is technically busy but unresponsive. Standard monitoring of `process_info(Pid, message_queue_len)` can identify the buildup, but it does not distinguish between a high-load state and a process stalled by a slow resource.

What are the recommended strategies for preventing a single blocked gen_server call from exhausting the entire connection pool without migrating to a different architecture? Additionally, is there a native mechanism to enforce a timeout on the execution of a `handle_call` callback to ensure the process returns to or handles the next message?