Conversation
If you feel that is the right approach, I really do not mind. These type of configuration are barely the "every day" situation. So, feel free to create a Try to keep safety checks at compile-time as much as we can. Make it work, then make it beautiful. |
fe6f5f9 to
d97f067
Compare
d97f067 to
5c37538
Compare
- Handle PID connection handles (hackney 2.x+ uses PIDs instead of refs) - Add finish_send_body call for streaming requests - Convert cacertfile to cacerts for hackney 3.x SSL compatibility - Use hackney_conn.body/2 for reading response body in hackney 3.x - Remove deprecated max_body test (hackney 3.x changed body reading API) - Require hackney >= 3.2.1 (fixes recv_timeout with connection pooling) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
5c37538 to
b4e3ac3
Compare
|
@tomekowal should I merge #498 and ideally, if possible, your upgrade would tackle it? |
|
Yeah. I am totally fine rebasing on top of that work :) |
|
Actually double guessing myself, I haven't use hackney enough to feel confident taking it 😭 |
|
Ah. I see. Then I'll try to take a look and review streaming PR. I am at ElixirConf EU right now, so this weekend I am traveling and won't be able to tackle it. I'll try to find some time first weekend of May (but can't promise anything). I think it makes sense to merge streaming first and then upgrade both :) |
This PR is a starting point on supporting hackney 2.x by tesla.
So far:
TBD:
TODO:
Note: the tests here are green because they still use old hackney. On new version