proxy: Figure out the plan for Hyper 1.0 migration #8733

olix0r · 2022-06-23T20:53:20Z

Hyper is planning a major 1.0 milestone that will impact many of their public APIs and, therefore, the proxy. We should get a better understanding of the planned changes so that we can begin to scope and plan the required proxy changes (and so that we can provide meaningful feedback before the APIs are finalized).

"here's some links!" -kate 💐 🧢

issues and pull requests related to upgrading linkerd2 to hyper 1.0:

in particular, this PR:

chore(deps): upgrade to hyper 1.x linkerd2-proxy#3504

The text was updated successfully, but these errors were encountered:

hawkw · 2022-06-23T21:05:13Z

Some of the things that are definitely worth keeping an eye on:

The future of hyper's use of the Service trait: whether hyper will use tower::Service in 1.0 is currently up in the air. If tower-service isn't 1.0 in time, it definitely won't. The question then becomes whether hyper will provide its own Service trait, or whether the interface will be changed significantly, potentially to one where user code calls into hyper.

If hyper ends up moving away from tower-service, there will definitely need to be some kind of glue layer (which could be a generic tower-hyper crate or similar); the complexity of this adapter will depend on how different the interfaces end up being.
I/O traits: It's unclear whether hyper 1.0 is going to use Tokio's AsyncRead/AsyncWrite traits (as it does currently), or something else.
- It seems like the use of the Tokio traits is more likely than the version from futures, but not set in stone, especially if there's an eventual plan for AsyncRead/AsyncWrite in std.
- There are also questions about whether the style of async I/O traits currently in tokio and in futures-io can ever efficiently support io_uring-style async IO, where ownership of the buffer is transferred to the I/O resource (and then to the OS). This is a broader ecosystem-level question, but it's worth keeping an eye on.
A bunch of stuff currently in hyper will move to hyper-util. This one is not a huge deal as that should generally be a pretty mechanical transformation.

stale · 2022-09-21T23:01:52Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

risingspiral · 2023-09-12T22:12:26Z

https://docs.rs/hyper/1.0.0-rc.4/hyper/

this is a prepatory chore, laying more ground to facilitate upgrading our hyper dependency to the 1.0 major release. this commit adds the `deprecated` cargo feature to each of the hyper dependencies in the cargo workspace. to prevent this from introducing a large number of compiler warnings to the build, the `#[allow(deprecated)]` attribute is added to relevant expressions. these uses of deprecated interfaces will be updated in subsequent commits. broadly, these fall into a few common cases: * `hyper::client::conn::SendRequest` now has protocol specific `h1` and `h2` variants. * `hyper::server::conn::Builder` now has protocol specific `h1` and `h2` variants. * `hyper::server::conn::Http` is deprecated. * functions like `hyper::body::aggregate(..)` and `hyper::body::to_bytes(..)` are deprecated. see linkerd/linkerd2#8733 for more information on the hyper 1.0 upgrade process. Signed-off-by: katelyn martin <kate@buoyant.io>

cratelyn · 2024-12-02T19:57:06Z

i've been driving this work forward recently, and was kindly pointed at this issue by @olix0r. i thought i'd lay down some thoughts on the work done thus far:

first, i drove a few small exploratory spikes into upgrading the proxy here, here, and here.

most of the friction related to this upgrade will be found in the linkerd-proxy-http crate, which provides a number of core facilities wrapping hyper's client and server interfaces used throughout the rest of the proxy.

i've landed a few preparatory changes, in linkerd/linkerd2-proxy#3379, linkerd/linkerd2-proxy#3380, and linkerd/linkerd2-proxy#3382. these pulled assorted standalone bits of http/hyper infrastructure that define http_body::Body middleware out of the linkerd-proxy-http library, and into their own distinct crates.

this will let us bump linkerd-http-classify, linkerd-http-stream-timeouts, linkerd-http-retain, linkerd-http-override-authority, [..] and other linkerd-http-* crates up to hyper 1.0 in separate steps, which should both facilitate review and mitigate the risk of bugs slipping in while addressing the changes to the Body trait in particular.

🥚 🔜 🐣 next steps

next, we can use the deprecated and backports feature flags provided in the 0.14 minor release to further prepare for the upgrade.

linkerd/linkerd2-proxy#3405 adds the deprecated flag to the hyper dependencies in the cargo workspace, and #[allow(deprecated)] attributes to code using deprecated hyper interfaces.

next, we'll address those deprecations, making use of the backports feature. i've landed hyperium/hyper#3796 upstream to backport a 1.0 interface that we'll need before we can use the connection builder backported to 0.14.

this is a prepatory chore, laying more ground to facilitate upgrading our hyper dependency to the 1.0 major release. this commit adds the `deprecated` cargo feature to each of the hyper dependencies in the cargo workspace. to prevent this from introducing a large number of compiler warnings to the build, the `#[allow(deprecated)]` attribute is added to relevant expressions. these uses of deprecated interfaces will be updated in subsequent commits. broadly, these fall into a few common cases: * `hyper::client::conn::SendRequest` now has protocol specific `h1` and `h2` variants. * `hyper::server::conn::Builder` now has protocol specific `h1` and `h2` variants. * `hyper::server::conn::Http` is deprecated. * functions like `hyper::body::aggregate(..)` and `hyper::body::to_bytes(..)` are deprecated. see linkerd/linkerd2#8733 for more information on the hyper 1.0 upgrade process. Signed-off-by: katelyn martin <kate@buoyant.io>

cratelyn · 2024-12-03T20:03:43Z

Some of the things that are definitely worth keeping an eye on:

* **The future of `hyper`'s use of the `Service` trait**: [whether `hyper` will use `tower::Service` in 1.0](https://github.com/hyperium/hyper/blob/master/docs/ROADMAP.md#service) is currently up in the air. If `tower-service` isn't 1.0 in time, it definitely won't. The question then becomes whether `hyper` will provide its own `Service` trait, or whether the interface will be changed significantly, [potentially to one where user code calls into `hyper`](https://github.com/hyperium/hyper/blob/master/docs/ROADMAP.md#you-call-hyper-or-hyper-calls-you).
  If hyper ends up moving away from `tower-service`, there will definitely need to be some kind of glue layer (which could be a generic `tower-hyper` crate or similar); the complexity of this adapter will depend on how different the interfaces end up being.

* **I/O traits**: It's unclear [whether `hyper` 1.0 is going to use Tokio's `AsyncRead`/`AsyncWrite` traits (as it does currently), or something else](https://github.com/hyperium/hyper/blob/master/docs/ROADMAP.md#runtime-woes).
  
  * It seems like the use of the Tokio traits is more likely than the version from `futures`, but not set in stone, especially if there's an eventual plan for `AsyncRead`/`AsyncWrite` in `std`.
  * There are also questions about whether the style of async I/O traits currently in `tokio` and in `futures-io` can ever efficiently support `io_uring`-style async IO, where ownership of the buffer is transferred to the I/O resource (and then to the OS).  This is a broader ecosystem-level question, but it's worth keeping an eye on.

* **A bunch of stuff currently in `hyper` will move to `hyper-util`.** This one is not a huge deal as that should _generally_ be a pretty mechanical transformation.

for the sake of closing the loop on the details above:

Service trait: hyper now provides its own Service trait. glue connecting tower to hyper lives in the hyper-util library: here.
I/O traits: hyper provides its own Read and Write traits. glue connecting this to tokio's traits lives in hyper-util::rt::tokio.
hyper-util motion: legacy client builder interfaces can be found in hyper_util::client::legacy. see hyper-util::server as well.

hyper 0.14.x provided a collection of interfaces related to collecting and aggregating request and response bodies, which were deprecated and removed in the 1.x major release. this commit updates calls to `hyper::body::to_bytes(..)` and `hyper::body::aggregate(..)`. for now, `http_body::Body` is used, but we can use `http_body_util::BodyExt` once we've bumped our hyper dependency to the 1.x major release. for more information, see: * linkerd/linkerd2#8733 * hyperium/hyper#2840 * hyperium/hyper#3020 Signed-off-by: katelyn martin <kate@buoyant.io>

* chore(app/admin): add `http-body` dependency before we address deprecated hyper interfaces related to `http_bodies`, we'll want to add this dependency so that we can call `Body::collect()`. Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(app): update deprecated hyper body calls hyper 0.14.x provided a collection of interfaces related to collecting and aggregating request and response bodies, which were deprecated and removed in the 1.x major release. this commit updates calls to `hyper::body::to_bytes(..)` and `hyper::body::aggregate(..)`. for now, `http_body::Body` is used, but we can use `http_body_util::BodyExt` once we've bumped our hyper dependency to the 1.x major release. for more information, see: * linkerd/linkerd2#8733 * hyperium/hyper#2840 * hyperium/hyper#3020 Signed-off-by: katelyn martin <kate@buoyant.io> --------- Signed-off-by: katelyn martin <kate@buoyant.io>

cratelyn · 2024-12-04T19:51:18Z

with linkerd/linkerd2-proxy#3405 landed, we're now in a good position to begin addressing particular deprecations in the hyper 0.14.31 interface to prepare the proxy for the hyper 1.0 upgrade.

linkerd/linkerd2-proxy#3411 is an example of one such change, handling calls to deprecated hyper::body functions such as e.g. aggregate().

this `Server` type is not used by any tests. this commit removes it, to help facilitate the upgrade to the hyper 1.0 major release. see <linkerd/linkerd2#8733>. Signed-off-by: katelyn martin <kate@buoyant.io>

#3427) this branch contains a sequence of commits that focus on addressing deprecation warnings related to hyper::client::conn::Builder. this branch enables the backports feature, and then replaces some of these builders with the backported, http/2 specific, hyper::client::conn::http2::Builder type. relates to linkerd/linkerd2#8733. --- * chore(proxy/http): address `h2::Connection` deprecation this commit updates `Connection` to use the backported, http/2 specific `SendRequest` type. this commit enables the `backports` feature flag in the `hyper` dependency. Signed-off-by: katelyn martin <kate@buoyant.io> * chore(proxy/http): address `server::tests` deprecations Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(proxy/http): consolidate connect functions `connect()` is never called elsewhere. let's avoid the misdirection and move it into the body of `connect_h2()`. Signed-off-by: katelyn martin <kate@buoyant.io> --------- Signed-off-by: katelyn martin <kate@buoyant.io>

while handling the upgrade to hyper 1.0, i noticed some small changes that'd be nice to make. most importantly, with respect to linkerd/linkerd2#8733, this commit outlines `http_util::http_request()`. hyper 1.0 provides version specific `SendRequest` types for HTTP/1 and HTTP/2, so rather than try to be polymorphic across both senders, we send the request at the call site. two other commits remove `pub` attributes for functions that aren't called externally. we'll address `run_proxy()` and `connect_client()` in a subsequent PR, because the dependent tests use both HTTP/1 and HTTP/2. --- * refactor(app/test): remove `pub` from `http_util::connect_client()` this is not used elsewhere. it can be private. Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(app/test): remove `pub` from `http_util::run_proxy()` Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(app/test): remove `http_util::http_request()` this function abstracts over one statement, at the cost of needing to name the `SendRequest` type. because hyper's 1.0 interface provides multiple `SendRequest` types based on the HTTP version being used. to avoid needing to deal with polymorphism, and to implicitly address a function-level allowance of deprecated types, we remove this function and move this statement to the function's call sites. Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(app/test): collect bodies with `String::from_utf8` this function previously called `std::str::from_utf8`, before calling `str::to_owned` on the result. because of this, there is a bit of extra gymnastics, passing a `&body[..]` slice along after collecting the body bytes. this is both more baroque and less performant. this commit updates the call, using `String::from_utf8` to collect the body, sparing a needless `to_owned()`/`clone()` call. Signed-off-by: katelyn martin <kate@buoyant.io> * docs(app/test): document `io` submodule Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(app/test): remove duplicate `io` reëxport the same `pub use` bundle is found in the parent `lib.rs`. this removes it, and refers to the same `mod io {}` defined above. Signed-off-by: katelyn martin <kate@buoyant.io> * review(app/inbound): use `ServiceExt::oneshot(..)` #3428 (comment) we can simplify these statements sending requests, by using `ServiceExt::oneshot(..)`. Signed-off-by: katelyn martin <kate@buoyant.io> --------- Signed-off-by: katelyn martin <kate@buoyant.io>

this addresses hyper 1.0 deprecations in the server side of the inbound proxy's http unit test suite logic. see <linkerd/linkerd2#8733> for more information. the client end of this change ends up being slightly involved, due to changes that will need to be made in `linkerd_app_test::http_util`. accordingly, those deprecations will be addressed in a subsequent commit. Signed-off-by: katelyn martin <kate@buoyant.io>

pr's #3564 and #3567, 1eb822f and 3204278 respectively, replaced uses of defunct `http_body::Body` trait methods — namely, `data()` and `trailers()`. this commit updates two remaining uses of `data()` that were missed in this initial pass. see linkerd/linkerd2#8733 for more information. Signed-off-by: katelyn martin <kate@buoyant.io>

we have a unit test, called `eos_only_when_fully_replayed` that confirms `Body::end_of_stream()` reports the stream ending properly. soon, we aim to introduce additional test coverage that exercises this when a body has trailers, as well. this will be useful for assurance related to upgrading to http-body v1.x. see linkerd/linkerd2#8733 for more information. unfortunately, hyper 0.14's channel-backed body does not report itself as having reached the end of the stream. this is an unfortunate quality that prevents us from using `Test::new()`. this commit adds a `TestBody` type that we can use in place of `BoxBody::from_static(..)`, which boxes a static string, but does not send trailers. Signed-off-by: katelyn martin <kate@buoyant.io>

this commit introduces additional test coverage that exercises `is_end_stream()` when a replay body is wrapping a body with trailers. this will be useful for assurance related to upgrading to http-body v1.x. see linkerd/linkerd2#8733 for more information. Signed-off-by: katelyn martin <kate@buoyant.io>

see linkerd/linkerd2#8733. we are currently in the process of upgrading our hyper, http, and http-body dependencies to their 1.0 major releases. this branch introduces additional test coverage, and further refines existing test coverage, concerning how a `ReplayBody` behaves when it reaches the "end of stream" of its internal `B`-typed body. additional assertions are added to show that bodies with trailers may be replayed an arbitrary number of times, and that capacity errors occur precisely at their expected boundary. additional assertions are added to confirm that `ReplayBody::is_capped()` reports these conditions properly. this branch also notably outlines the unit test suite into a separate file, due to its size. as a result, reviewers are encouraged to walk through this branch on a commit-by-commit basis when reading these changes. i noticed some relatively minor issues with `is_end_stream()` and `size_hint()` while i was reviewing this middleware, in preparation to port it to http-body 1.0. i have left `TODO` comments noting where today's behavior is slightly askew, but _intentionally avoided_ fixing them here. my goal on that front is to highlight those wrinkles so that later fixes to these edges are more easily reviewable. --- * refactor(http/retry): outline `ReplayBody` unit tests there are more than 500 lines of unit tests. let's move them into a submodule, for convenience. Signed-off-by: katelyn martin <kate@buoyant.io> * nit(http/retry): reorganize replay tests this is a small cosmetic change reording some test helpers. there is a common convention of affixing a banner comment above groups of `impl T {}` blocks, which is useful when top-level blocks are folded in an editor. similarly, there is a convention of defining structures at the top of a file. this commit reorganizes the replay body tests to follow each of these conventions. Signed-off-by: katelyn martin <kate@buoyant.io> * nit(http/retry): test replays trailers twice just to be extra sure! Signed-off-by: katelyn martin <kate@buoyant.io> * nit(http/retry): rename `trailers_only()` test this is part of a family of other tests called `replays_one_chunk()`, `replays_several_chunks()`, and `replays_trailers()`. let's name this something that lines up with this convention. Signed-off-by: katelyn martin <kate@buoyant.io> * feat(http/retry): add a `TestBody` type we have a unit test, called `eos_only_when_fully_replayed` that confirms `Body::end_of_stream()` reports the stream ending properly. soon, we aim to introduce additional test coverage that exercises this when a body has trailers, as well. this will be useful for assurance related to upgrading to http-body v1.x. see linkerd/linkerd2#8733 for more information. unfortunately, hyper 0.14's channel-backed body does not report itself as having reached the end of the stream. this is an unfortunate quality that prevents us from using `Test::new()`. this commit adds a `TestBody` type that we can use in place of `BoxBody::from_static(..)`, which boxes a static string, but does not send trailers. Signed-off-by: katelyn martin <kate@buoyant.io> * feat(http/retry): add `is_end_stream()` coverage for trailers this commit introduces additional test coverage that exercises `is_end_stream()` when a replay body is wrapping a body with trailers. this will be useful for assurance related to upgrading to http-body v1.x. see linkerd/linkerd2#8733 for more information. Signed-off-by: katelyn martin <kate@buoyant.io> * feat(http/retry): add `is_capped()` test coverage Signed-off-by: katelyn martin <kate@buoyant.io> * feat(http/retry): further refine capacity test coverage we want to show that exceeding the capacity is the point at which replays will fail. this commit defines some constants to further communicate and encode this relationship between the bytes sent, and the capacity of the replay body. further, it shortens the second frame sent so that we ensure precisely when a body becomes capped. Signed-off-by: katelyn martin <kate@buoyant.io> * feat(http/retry): add `size_hint()` test coverage Signed-off-by: katelyn martin <kate@buoyant.io> * chore(http/retry): add todo comments concerning eos for now, a replaying body that will not yield trailers must be polled to the `None` before reporting itself as reaching the end of the stream. this isn't hugely important, but does affect some test control flow. leave two todo comments so that if/when upgrading to hyper 1.0, it is clear that these are not load-bearing or otherwise expected behavior, should this behavior be rectified. Signed-off-by: katelyn martin <kate@buoyant.io> --------- Signed-off-by: katelyn martin <kate@buoyant.io>

this commit makes some small, admittedly subjective tweaks to `ReplayBody::poll_trailers(..)`. we can make use of the `map_ok` and `map_err` methods that exist to map `Poll::Ready<Result<T, E>>`'s inner `T` to some `U` (in our case, to record the trailers for later replay), and to map the error type into a boxed `Error`. this is a minor tweak, front-running other work to port the `ReplayBody` to http-body 1.0. see linkerd/linkerd2#8733. Signed-off-by: katelyn martin <kate@buoyant.io>

pr #3559 (dd4fbcd) refactored our trailer peeking body middleware to model its buffering in terms of the `Frame<T>` type used in `http-body`'s 1.0 release. this commit performs a similar change for the other piece of body middleware that super linkerd's retry facilities: `ReplayBody`. the inner body `B` is now wrapped in the `ForwardCompatibleBody` adapter, and we now poll it in terms of frames. NB: polling the underlying in terms of frames has a subtle knock-on effect regarding when we observe the trailers, in the liminal period between this refactor and the subsequent upgrade to hyper 1.0, whilst we must still implement the existing 0.4 interface for `Body` that includes `poll_trailers()`. see the comment above `replay_trailers` for more on this, describing why we now initialize this to `true`. relatedly, this is why we now longer delegate down to `B::poll_trailers` ourselves. it will have already been called by our adapter. `ReplayBody::is_end_stream()` now behaves identically when initially polling a body compared to subsequent replays. this is fine, as `is_end_stream()` is a hint that facilitates optimizations. we do still report the end properly, we just won't be quite as prescient on the initial playthrough. see: - linkerd/linkerd2#8733. - #3559 Signed-off-by: katelyn martin <kate@buoyant.io>

pr #3559 (dd4fbcd) refactored our trailer peeking body middleware to model its buffering in terms of the `Frame<T>` type used in `http-body`'s 1.0 release. this commit performs a similar change for the other piece of body middleware that super linkerd's retry facilities: `ReplayBody`. the inner body `B` is now wrapped in the `ForwardCompatibleBody` adapter, and we now poll it in terms of frames. NB: polling the underlying in terms of frames has a subtle knock-on effect regarding when we observe the trailers, in the liminal period between this refactor and the subsequent upgrade to hyper 1.0, whilst we must still implement the existing 0.4 interface for `Body` that includes `poll_trailers()`. see the comment above `replay_trailers` for more on this, describing why we now initialize this to `true`. relatedly, this is why we now longer delegate down to `B::poll_trailers` ourselves. it will have already been called by our adapter. `ReplayBody::is_end_stream()` now behaves identically when initially polling a body compared to subsequent replays. this is fine, as `is_end_stream()` is a hint that facilitates optimizations (hyperium/http-body#143). we do still report the end properly, we just won't be quite as prescient on the initial playthrough. see: - linkerd/linkerd2#8733. - #3559 Signed-off-by: katelyn martin <kate@buoyant.io>

the `ReplayBody` middleware makes use of a `BufList` type to hold a reference to bytes yielded by the inner body `B`. a `Data` enum is composed on top to this, to allow bodies to either return (a) a replay of a previous body, or (b) the iniial bytes yielded by the original body. this branch also takes the step of moving some code out of the `ReplayBody::poll_data(..)` trait method along with inlining `BufList::push_chunk(..)` , a small helper function that is only used once. this is intended to consolidate code related to buffering data yielded by the underlying `B`-typed body, and extricate logic concerning the bounding of this buffer from the now defunct `Body::poll_data()` trait method. see linkerd/linkerd2#8733 for more information about upgrading the proxy to hyper 1.0. this will help make subsequent changes to the model of `ReplayBody` its corresponding `Body` implementation more reviewable, by proactively reorganizing things in advance. --- * refactor(http/retry): outline replay buffer the replay body uses this `BufList` type to hold a reference to bytes yielded by the inner body `B`. the `Data` enum is composed on top to this, to allow bodies to either return a replay of a previous body, or the iniial bytes yielded by the original body. this is all relatively self-contained, so we can move this into a small submodule. Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(http/retry): outline replay body buffering this commit moves some code out of the `ReplayBody::poll_data(..)` trait method. this bit of code is where we take a chunk of a data yielded by the inner body, and push it into our replay buffer. if the capacity is exceeded, we flush the buffer. in either case, the code copies the chunk into a cheaply cloneable, contiguous `Bytes`. this is all related to the buffer, so we move it there. Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(http/retry): inline `BufList::push_chunk` `push_chunk` is a small helper function that is only used once. now that we have moved our buffering code alongside this type, it's more straightforward to inline this function. Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(http/retry): rename `BufList` to `Replay` this structure is responsible for acting as the `bytes::Buf` buffer for the replay of the initial body. this commit renames this to articulate that relationship more directly. Signed-off-by: katelyn martin <kate@buoyant.io> * docs(http/retry): polish `Replay` documentation Signed-off-by: katelyn martin <kate@buoyant.io> --------- Signed-off-by: katelyn martin <kate@buoyant.io>

pr #3559 (dd4fbcd) refactored our trailer peeking body middleware to model its buffering in terms of the `Frame<T>` type used in `http-body`'s 1.0 release. this commit performs a similar change for the other piece of body middleware that super linkerd's retry facilities: `ReplayBody`. the inner body `B` is now wrapped in the `ForwardCompatibleBody` adapter, and we now poll it in terms of frames. NB: polling the underlying in terms of frames has a subtle knock-on effect regarding when we observe the trailers, in the liminal period between this refactor and the subsequent upgrade to hyper 1.0, whilst we must still implement the existing 0.4 interface for `Body` that includes `poll_trailers()`. see the comment above `replay_trailers` for more on this, describing why we now initialize this to `true`. relatedly, this is why we now longer delegate down to `B::poll_trailers` ourselves. it will have already been called by our adapter. `ReplayBody::is_end_stream()` now behaves identically when initially polling a body compared to subsequent replays. this is fine, as `is_end_stream()` is a hint that facilitates optimizations (hyperium/http-body#143). we do still report the end properly, we just won't be quite as prescient on the initial playthrough. see: - linkerd/linkerd2#8733. - #3559 Signed-off-by: katelyn martin <kate@buoyant.io>

pr #3559 (dd4fbcd) refactored our trailer peeking body middleware to model its buffering in terms of the `Frame<T>` type used in `http-body`'s 1.0 release. this branch performs a similar change for the other piece of body middleware that super linkerd's retry facilities: `ReplayBody`. the inner body `B` is now wrapped in the `ForwardCompatibleBody` adapter, and we now poll it in terms of frames. NB: polling the underlying in terms of frames has a subtle knock-on effect regarding when we observe the trailers, in the liminal period between this refactor and the subsequent upgrade to hyper 1.0, whilst we must still implement the existing 0.4 interface for `Body` that includes `poll_trailers()`. see the comment above `replay_trailers` for more on this, describing why we now initialize this to `true`. relatedly, this is why we no longer delegate down to `B::poll_trailers` ourselves. it will have already been called by our adapter. `ReplayBody::is_end_stream()` now behaves identically when initially polling a body compared to subsequent replays. this is fine, as `is_end_stream()` is a hint that facilitates optimizations (hyperium/http-body#143). we do still report the end properly, we just won't be quite as prescient on the initial playthrough. in the same manner as the existing `frame()` method mimics `http_body_util::BodyExt::frame()`, this branch introduces a new `ForwardCompatibleBody::poll_frame()` method. this allows us to poll the compatibility layer for a `Frame<T>`. see: - linkerd/linkerd2#8733. - #3559 --- * nit(http/retry): install tracing subscriber in tests some tests do not set up a tracing subscriber, because they do not use the shared `Test::new()` helper function used elsewhere in this test suite. to provide a trace of the test's execution in the event of a failure, initialize a tracing subscriber in some additional unit tests. Signed-off-by: katelyn martin <kate@buoyant.io> * feat(http/retry): `ForwardCompatibleBody` exposes hints this commit removes the `cfg(test)` gate on the method exposing `B::is_end_stream()`, and introduces another method also exposing the `size_hint()` method. we will want these in order to implement these methods for `ReplayBody`. Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(http/retry): `ForwardCompatibleBody::poll_frame()` in the same manner as the existing `frame()` method mimics `http_body_util::BodyExt::frame()`, this commit introduces a new `ForwardCompatibleBody::poll_frame()` method. this allows us to poll the compatibility layer for a `Frame<T>`. Signed-off-by: katelyn martin <kate@buoyant.io> * feat(http/retry): `ReplayBody` polls for frames pr #3559 (dd4fbcd) refactored our trailer peeking body middleware to model its buffering in terms of the `Frame<T>` type used in `http-body`'s 1.0 release. this commit performs a similar change for the other piece of body middleware that super linkerd's retry facilities: `ReplayBody`. the inner body `B` is now wrapped in the `ForwardCompatibleBody` adapter, and we now poll it in terms of frames. NB: polling the underlying in terms of frames has a subtle knock-on effect regarding when we observe the trailers, in the liminal period between this refactor and the subsequent upgrade to hyper 1.0, whilst we must still implement the existing 0.4 interface for `Body` that includes `poll_trailers()`. see the comment above `replay_trailers` for more on this, describing why we now initialize this to `true`. relatedly, this is why we now longer delegate down to `B::poll_trailers` ourselves. it will have already been called by our adapter. `ReplayBody::is_end_stream()` now behaves identically when initially polling a body compared to subsequent replays. this is fine, as `is_end_stream()` is a hint that facilitates optimizations (hyperium/http-body#143). we do still report the end properly, we just won't be quite as prescient on the initial playthrough. see: - linkerd/linkerd2#8733. - #3559 Signed-off-by: katelyn martin <kate@buoyant.io> * feat(http/retry): `is_end_stream()` traces this commit introduces some trace-level diagnostics tracking how the replay body has determined whether or not it has reached the end of the stream. Signed-off-by: katelyn martin <kate@buoyant.io> * nit(http/retry): capitalize trace event messages Signed-off-by: katelyn martin <kate@buoyant.io> --------- Signed-off-by: katelyn martin <kate@buoyant.io>

note: this commit will not compile, code changes are intentionally elided from this commit. this commit upgrades hyper, http, tonic, prost, related dependencies, and their assorted cargo features. see <linkerd/linkerd2#8733>. Signed-off-by: katelyn martin <kate@buoyant.io>

in #3559 (4b53081), we introduced a backported `Frame<T>` type, and a `ForwardCompatibleBody` type that allows us to interact with a `http_body::Body` circa 0.4.6 in terms of frame-based interfaces that match those of the 1.0 interface. see linkerd/linkerd2#8733 for more information on upgrading hyper. in #3559, we narrowly added this as an internal submodule of the `linkerd-http-retry` library. these facilities however, would have utility in other places such as `linkerd-app-core`. this commit pulls these compatibility shims out into a `linkerd-http-body-compat` library so that they can be imported and reused elsewhere. Signed-off-by: katelyn martin <kate@buoyant.io>

this commit introduces a test suite for our error recovery middleware. this body middleware provides a mechanism to "rescue" errors, gracefully mapping an error encountered when polling a gRPC body into e.g. trailers with a gRPC status code. before we upgrade this middleware in service of linkerd/linkerd2#8733, we add some test coverage to ensure that we preserve this middleware. Signed-off-by: katelyn martin <kate@buoyant.io>

* refactor(http/retry): outline `ForwardCompatibleBody` in #3559 (4b53081), we introduced a backported `Frame<T>` type, and a `ForwardCompatibleBody` type that allows us to interact with a `http_body::Body` circa 0.4.6 in terms of frame-based interfaces that match those of the 1.0 interface. see linkerd/linkerd2#8733 for more information on upgrading hyper. in #3559, we narrowly added this as an internal submodule of the `linkerd-http-retry` library. these facilities however, would have utility in other places such as `linkerd-app-core`. this commit pulls these compatibility shims out into a `linkerd-http-body-compat` library so that they can be imported and reused elsewhere. Signed-off-by: katelyn martin <kate@buoyant.io> * nit(http/body-compat): tidy `combinators` imports Signed-off-by: katelyn martin <kate@buoyant.io> --------- Signed-off-by: katelyn martin <kate@buoyant.io>

`linkerd-app-core` includes an error recovery body middleware. this middleware will gracefully catch and report errors encountered when polling an inner body, and via an `R`-typed recovery strategy provided by the caller, will attempt to map the error to a gRPC status code denoting an error. before we upgrade to hyper 1.0 in service of linkerd/linkerd2#8733, we add some test coverage to ensure that we preserve the behavior of this middleware. see: * linkerd/linkerd2#8733 * #3614. for historical context on this tower layer, see: * #222 * #1246 * #1282 --- * refactor(http/retry): outline `ForwardCompatibleBody` in #3559 (4b53081), we introduced a backported `Frame<T>` type, and a `ForwardCompatibleBody` type that allows us to interact with a `http_body::Body` circa 0.4.6 in terms of frame-based interfaces that match those of the 1.0 interface. see linkerd/linkerd2#8733 for more information on upgrading hyper. in #3559, we narrowly added this as an internal submodule of the `linkerd-http-retry` library. these facilities however, would have utility in other places such as `linkerd-app-core`. this commit pulls these compatibility shims out into a `linkerd-http-body-compat` library so that they can be imported and reused elsewhere. Signed-off-by: katelyn martin <kate@buoyant.io> * nit(http/body-compat): tidy `combinators` imports Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(app/core): hoist `errors::code_header` helper Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(app/core): `l5d-*` constants are headers these are header values. `http::HeaderName` has a const fn constructor, so let's use that. Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(app/core): grpc constants are headers Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(app/core): hoist `l5d-` and `grpc-` constants Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(app/core): outline `ResponseBody` middleware we'll add a few tests for this middleware shortly. this commit moves this middleware out into its own submodule. Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(app/core): encapsulate `ResponseBody` enum for other body middleware, we hide inner enum variants and their constituent members by using the "inner" pattern. this commit tweaks `ResponseBody` to follow suit, such that it now holds an `Inner`, but does not expose its passthrough and rescue variants to callers. Signed-off-by: katelyn martin <kate@buoyant.io> * docs(app/core): document `ResponseBody<R, B>` this adds a small documentation comment describing what this type does. Signed-off-by: katelyn martin <kate@buoyant.io> * refactor(app/core): a unit test suite for rescue body this commit introduces a test suite for our error recovery middleware. this body middleware provides a mechanism to "rescue" errors, gracefully mapping an error encountered when polling a gRPC body into e.g. trailers with a gRPC status code. before we upgrade this middleware in service of linkerd/linkerd2#8733, we add some test coverage to ensure that we preserve this middleware. Signed-off-by: katelyn martin <kate@buoyant.io> --------- Signed-off-by: katelyn martin <kate@buoyant.io>

this commit makes some minor alterations to our error recovery body middleware. see linkerd/linkerd2#8733 for more information. this commit removes an `assert!` statement from the implementation of `<Response<R, B> as Body>::poll_data()`. see the documentation of `Body::poll_frame()`: > Once the end of the stream is reached, implementations should > continue to return [`Poll::Ready(None)`]. hyperium/http-body@1090bff#diff-33aabe8c2aaa7614022addf244245e09bbff576a67a9ae3c6938c8a868201d36R60-R61 to do this, this commit introduces a distinct terminal state `Inner::Rescued` to represent when the underlying `B`-typed body has yielded an error and been rescued. once in this state the body will yield no more data frames, instead yielding a collection of trailers describing the mid-stream error that was encountered by the underlying body. the call to `R::rescue` is also moved down into the helper function fka `grpc_trailers()`. this helps the function follow the grain of our "state machine" a little more directly. see #3615, #3614, and #3611 for pretext to this change.

this commit makes some minor alterations to our error recovery body middleware. see linkerd/linkerd2#8733 for more information. this commit removes an `assert!` statement from the implementation of `<Response<R, B> as Body>::poll_data()`. see the documentation of `Body::poll_frame()`: > Once the end of the stream is reached, implementations should > continue to return [`Poll::Ready(None)`]. hyperium/http-body@1090bff#diff-33aabe8c2aaa7614022addf244245e09bbff576a67a9ae3c6938c8a868201d36R60-R61 to do this, this commit introduces a distinct terminal state `Inner::Rescued` to represent when the underlying `B`-typed body has yielded an error and been rescued. once in this state the body will yield no more data frames, instead yielding a collection of trailers describing the mid-stream error that was encountered by the underlying body. the call to `R::rescue` is also moved down into the helper function fka `grpc_trailers()`. this helps the function follow the grain of our "state machine" a little more directly. see #3615, #3614, and #3611 for pretext to this change. Signed-off-by: katelyn martin <kate@buoyant.io>

note: this commit will not compile, code changes are intentionally elided from this commit. this commit upgrades hyper, http, tonic, prost, related dependencies, and their assorted cargo features. see <linkerd/linkerd2#8733>. Signed-off-by: katelyn martin <kate@buoyant.io>

olix0r added the area/proxy label Jun 23, 2022

olix0r added this to the stable-2.13.0 milestone Jun 23, 2022

stale bot added the wontfix label Sep 21, 2022

adleong added pinned and removed wontfix labels Sep 22, 2022

adleong modified the milestones: stable-2.13.0, stable-2.14.0 Jan 19, 2023

risingspiral removed this from the stable-2.14.0 milestone Aug 4, 2023

cratelyn self-assigned this Dec 2, 2024

cratelyn mentioned this issue Dec 2, 2024

chore(hyper): enable deprecated feature flag linkerd/linkerd2-proxy#3405

Merged

cratelyn mentioned this issue Dec 4, 2024

refactor(app): update deprecated hyper body calls linkerd/linkerd2-proxy#3411

Merged

cratelyn mentioned this issue Dec 4, 2024

refactor(app/test): remove unused test Server interfaces linkerd/linkerd2-proxy#3421

Merged

This was referenced Dec 5, 2024

chore(proxy/http): address hyper::client::conn::Builder deprecations linkerd/linkerd2-proxy#3427

Merged

refactor(app/test): minor tweaks to linkerd-app-test linkerd/linkerd2-proxy#3428

Merged

cratelyn mentioned this issue Dec 6, 2024

chore(app/inbound): address server::conn::Http deprecations linkerd/linkerd2-proxy#3432

Merged

cratelyn mentioned this issue Jan 28, 2025

refactor(http/retry): update more Body::data() calls linkerd/linkerd2-proxy#3573

Merged

cratelyn mentioned this issue Jan 30, 2025

feat(http/retry): add more replay body test coverage linkerd/linkerd2-proxy#3583

Merged

This was referenced Jan 31, 2025

refactor(http/retry): use Poll::{map_ok, map_err} linkerd/linkerd2-proxy#3586

Merged

refactor(http/retry): replayed body is not optional linkerd/linkerd2-proxy#3585

Merged

cratelyn mentioned this issue Feb 5, 2025

refactor(http/retry): outline bounded replay buffer linkerd/linkerd2-proxy#3597

Merged

cratelyn mentioned this issue Feb 6, 2025

feat(http/retry): model ReplayBody with Frame<T> linkerd/linkerd2-proxy#3598

Merged

cratelyn mentioned this issue Feb 12, 2025

build(deps): bump prost-build from 0.12.6 to 0.13.5 linkerd/linkerd2-proxy#3613

Closed

cratelyn mentioned this issue Feb 12, 2025

refactor(http/retry): outline ForwardCompatibleBody linkerd/linkerd2-proxy#3614

Merged

cratelyn mentioned this issue Feb 13, 2025

refactor(app/core): a unit test suite for rescue body linkerd/linkerd2-proxy#3615

Merged

cratelyn mentioned this issue Feb 14, 2025

refactor(app/core): prepare rescue body for http-body upgrade linkerd/linkerd2-proxy#3616

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

proxy: Figure out the plan for Hyper 1.0 migration #8733

proxy: Figure out the plan for Hyper 1.0 migration #8733

olix0r commented Jun 23, 2022 •

edited by cratelyn

Loading

hawkw commented Jun 23, 2022

stale bot commented Sep 21, 2022

risingspiral commented Sep 12, 2023

cratelyn commented Dec 2, 2024

cratelyn commented Dec 3, 2024

cratelyn commented Dec 4, 2024

proxy: Figure out the plan for Hyper 1.0 migration #8733

proxy: Figure out the plan for Hyper 1.0 migration #8733

Comments

olix0r commented Jun 23, 2022 • edited by cratelyn Loading

hawkw commented Jun 23, 2022

stale bot commented Sep 21, 2022

risingspiral commented Sep 12, 2023

cratelyn commented Dec 2, 2024

🥚 🔜 🐣 next steps

cratelyn commented Dec 3, 2024

cratelyn commented Dec 4, 2024

olix0r commented Jun 23, 2022 •

edited by cratelyn

Loading