david-perez

An internal user also reported that the error was confusing because they didn't know what these protocols were about. We could link for each protocol its doc page under https://smithy.io/2.0/aws/protocols/index.html

Something to keep in mind, from https://github.com/awslabs/smithy-rs/pull/2524#issuecomment-1491955247 > We should also think about having a mechanism to test that the framework is error logging what we expect it to; error...

Asking Smithy for guidance: https://github.com/smithy-lang/smithy/issues/2123

As we start adding support for new protocols (https://github.com/smithy-lang/smithy-rs/issues/3573), this task gains importance: existing services will want to make use of more modern protocols.

Deprioritized. It's unclear how the `endpoint` trait interacts with user-supplied endpoint configuration (coming from e.g. a middleware).

For the record, as of writing (cfd89422e639f53b380f8f99641df6792f7848d1), there's 210 tests in the server that fail to compile if we `--deny warnings`. [failing-tests.txt](https://github.com/smithy-lang/smithy-rs/files/13740773/failing-tests.txt)

We also generate crates with doc warnings (mostly broken links), but CI doesn't fail, despite us baking in `RUSTDOCFLAGS="-D warnings"` in the Docker image, because we clear `RUSTDOCFLAGS` in `CodegenTestCommon.kt`.

@andrewbanchich Why does #2858 solve this? In #2858, server operation handlers would take in types that implement [`FromRequest`](https://docs.rs/aws-smithy-http-server/latest/aws_smithy_http_server/request/trait.FromRequest.html), but `FromRequest` should only be implemented by the generated SDK on the...

I don't think we should let users implement `FromRequest` for their own types. In fact, I think we should doc-hide and seal the trait. If we allow users to implement...

This actually has no effect because the builder's fields are `pub(crate)`, and `#[non_exhaustive]` would only affect how users interact with it outside of the defining crate.