chore(deps): bump hackney from 4.7.4 to 4.8.2 in the prod group

[dependabot]

Bumps the prod group with 1 update: hackney.

Updates hackney from 4.7.4 to 4.8.2

Release notes

Sourced from hackney's releases.

hackney 4.8.2

Fixed

• A connection opened without a pool is owned by the process that opened it and closes when that process dies. It was started under hackney_conn_sup and owned by it, so a killed caller left the connection and its socket open until the server closed it (idle_timeout defaults to infinity). Covers request/5 and connect/* with {pool, false}, streamed request bodies, async responses, HTTP proxies, CONNECT and SOCKS5 tunnels, HTTP/2 and HTTP/3, and h2_open/* streams. With stream_to, the stream_to process owns the connection, as before. hackney_conn:set_owner/2 still moves ownership.
• An HTTP/1.1 connection waiting for a response closes within a second of its owner dying. It was blocked in the socket read and noticed only when the response came, the server closed, or recv_timeout expired.
• A CONNECT or SOCKS5 tunnel socket belongs to its connection. It stayed with the process that opened it, so after hackney_conn:set_owner/2 it still closed when that process died.

hackney 4.8.1

Changed

• Update quic to 2.0.1, which compiles on Windows again. Its NIF build and clean hooks ran through sh, which Windows lacks, so the compile failed there for anything that reaches quic, hackney included. Windows runs on OTP crypto.

hackney 4.8.0

Fixed

• hackney:send_request/2 works on HTTP/2 and HTTP/3. Those protocols answer a request with the body included, which the function did not handle, so it failed with a case_clause. It returns the connection on every protocol now, so the response is read with body/1 or pulled with stream_body/1.
• Several callers reading responses on one HTTP/2 or HTTP/3 connection each get their own. The read was resolved from the connection's last stream rather than the caller's, so on HTTP/2 all but one caller got {error, no_stream}, and on HTTP/3 two callers could be handed each other's body.
• A caller reading an HTTP/3 response with body/1 or stream_body/1 is answered when the server resets its stream, instead of waiting for its own timeout. Needs quic 2.0.0, the first release to report a peer RESET_STREAM.
• A pooled HTTP/2 connection no longer closes when the caller that opened it exits. It stayed owned by that caller, so its exit failed every other caller's request on the connection with {error, closed}. A shared connection now has no owner: each stream is tied to its own caller and is reset if that caller dies, and the connection closes itself once it has had no open stream for the pool timeout (#937, thanks @​smartinio).

... (truncated)

Changelog

Sourced from hackney's changelog.

4.8.2 - 2026-09-26

Fixed

• A connection opened without a pool is owned by the process that opened it and closes when that process dies. It was started under hackney_conn_sup and owned by it, so a killed caller left the connection and its socket open until the server closed it (idle_timeout defaults to infinity). Covers request/5 and connect/* with {pool, false}, streamed request bodies, async responses, HTTP proxies, CONNECT and SOCKS5 tunnels, HTTP/2 and HTTP/3, and h2_open/* streams. With stream_to, the stream_to process owns the connection, as before. hackney_conn:set_owner/2 still moves ownership.
• An HTTP/1.1 connection waiting for a response closes within a second of its owner dying. It was blocked in the socket read and noticed only when the response came, the server closed, or recv_timeout expired.
• A CONNECT or SOCKS5 tunnel socket belongs to its connection. It stayed with the process that opened it, so after hackney_conn:set_owner/2 it still closed when that process died.

4.8.1 - 2026-09-25

Changed

• Update quic to 2.0.1, which compiles on Windows again. Its NIF build and clean hooks ran through sh, which Windows lacks, so the compile failed there for anything that reaches quic, hackney included. Windows runs on OTP crypto.

4.8.0 - 2026-09-24

Fixed

• hackney:send_request/2 works on HTTP/2 and HTTP/3. Those protocols answer a request with the body included, which the function did not handle, so it failed with a case_clause. It returns the connection on every protocol now, so the response is read with body/1 or pulled with stream_body/1.
• Several callers reading responses on one HTTP/2 or HTTP/3 connection each get their own. The read was resolved from the connection's last stream rather than the caller's, so on HTTP/2 all but one caller got {error, no_stream}, and on HTTP/3 two callers could be handed each other's body.
• A caller reading an HTTP/3 response with body/1 or stream_body/1 is answered when the server resets its stream, instead of waiting for its own timeout. Needs quic 2.0.0, the first release to report a peer RESET_STREAM.
• A pooled HTTP/2 connection no longer closes when the caller that opened it exits. It stayed owned by that caller, so its exit failed every other

... (truncated)

Commits

• 81ebe00 Merge pull request #953 from benoitc/release/4.8.2
• 3705ae7 Release 4.8.2
• 73366b9 Merge pull request #952 from benoitc/fix/owner-limits
• a016d9c Hand a tunnel socket to its connection
• c38a682 Notice a dead owner during a blocking HTTP/1.1 read
• 45885fa Merge pull request #951 from benoitc/fix/direct-conn-owner
• a8a11da Own a direct connection by the process that opened it
• d9129f8 Merge pull request #950 from benoitc/release/4.8.1
• 20faebc Release 4.8.1
• e41c32d Merge pull request #949 from benoitc/release/4.8.0
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[cursor]

PR Summary

Medium Risk
Lockfile-only change to the optional HTTP client stack (hackney plus quic 2.x), where upstream connection-lifecycle and HTTP/2/3 fixes can alter runtime behavior for Hackney adapter users.

Overview
Updates the prod dependency lockfile to pull in hackney 4.8.2 (from 4.7.4), with transitive bumps to h2, quic (1.8.1 → 2.1.1), and webtransport.

There are no application or library code changes—only mix.lock. For consumers using Tesla.Adapter.Hackney, runtime behavior may shift with upstream fixes around connection/stream ownership, pooled HTTP/2, HTTP/3 response handling, and faster cleanup when owning processes die (per hackney 4.8.x release notes).

Review focus: integration tests against the Hackney adapter (pooled vs {pool, false}, streaming, HTTP/2/3 if used) and a clean compile on your target OTP/OS, since quic 2.x is a notable transitive jump.

^{Reviewed by Cursor Bugbot for commit 257fe24. Bugbot is set up for automated code reviews on this repo. Configure here.}