Support Finch tagged pools via :finch option tuple#539
Conversation
|
are the tests flacky? |
|
Since Req.get!("https://api.example.com/data", finch: MyFinch)
Req.get!("https://api.example.com/data", finch: {MyFinch, pool_tag: :bulk})
Req.get!("https://api.example.com/data", finch: {MyFinch, unix_socket: my_socket})Then if Finch were to ever add new options to |
|
PR updated with the last suggestions |
|
@jswanner I think |
|
I'm sorry, I was wrong before:
The above is only true for What are your thoughts, @wojtekmach? |
|
As an aside, one of the goals was to support multiple adapters and I still want to pursue it but Finch of course remains the default. That said, :unix_socket option is reasonable for other adapters but :pool_tag is Finch specific. So let’s keep :unix_socket as is, but suport finch: {name, pool_tag: tag}. There are some other Finch specific options, like :pool_max_idle_timeout or something like that, that I intend to move under finch: {name, options}. |
|
do we need to add other options? or do u prefer to merge/close this one and open another one? |
|
I'd prefer to merge just |
…_socket
Align with the new Finch API where pool_tag and unix_socket are build
options passed to Finch.build/5. Instead of exposing :pool_tag as a
top-level Req option, nest it under the :finch tuple:
Req.get!(url, finch: {MyFinch, pool_tag: :bulk})
Req.get!(url, finch: {MyFinch, unix_socket: "/tmp/sock"})
done! |
Summary
:finchoption to accept a{name, opts}tuple, allowing users to pass:pool_tagand:unix_socketdirectly toFinch.build/5.Finch.buildcall to use the 5thoptsargument, replacing the previousMap.replace!/2mutation pattern.Motivation
Finch supports configuring multiple connection pools for the same endpoint, differentiated by a tag via
Finch.Pool.new/2. This is useful for separating traffic by purpose (e.g., bulk ingestion vs. real-time queries) with different pool sizes and concurrency settings. Previously, there was no way to leverage this feature through Req without resorting to the low-level:finch_requestcallback.As suggested by @jswanner, since
:pool_tagand:unix_socketare only relevant when using your own Finch name, they are nested under the:finchoption rather than exposed as top-level Req options. This also means futureFinch.build/5options won't require Req changes to support.Usage
Changes
lib/req/finch.exfinch_build_opts/1to extract opts from{name, opts}tuple; updatefinch_name/1to handle tuple formlib/req/steps.exrun_finch/1docs to document the tuple APIlib/req.exReq.new/1docs for the:finchoptiontest/req/finch_test.exsfinch: {Req.Finch, pool_tag: :bulk}Backward Compatibility
Fully backward compatible. The
:finchoption continues to accept a plain atom name. The:unix_sockettop-level option still works when not using the tuple form. When:pool_tagis not specified,Finch.build/5defaults it to:default.