Client does not build with @streaming blob

[david-perez]

I don't understand why the following Smithy model:

$version: "1.0"

namespace com.amazonaws.simple

use aws.protocols#restJson1

@restJson1
@title("SimpleService")
service SimpleService {
    version: "2022-01-01",
    operations: [
        StreamingOperation,
    ],
}

@http(uri: "/streaming", method: "GET")
operation StreamingOperation {
    input: StreamingOperationInput,
    output: StreamingOperationOutput,
}

@input
structure StreamingOperationInput {}

@output
structure StreamingOperationOutput {
    output: StreamingBlob,
}

@streaming
blob StreamingBlob

fails to build.

error[E0308]: try expression alternatives have incompatible types
  --> simple/rust-codegen/src/json_deser.rs:19:29
   |
19 | / ...                   aws_smithy_json::deserialize::token::expect_blob_or_null(
20 | | ...                       tokens.next(),
21 | | ...                   )?,
   | |________________________^ expected struct `aws_smithy_http::byte_stream::ByteStream`, found struct `aws_smithy_types::Blob`
   |
   = note: expected enum `std::option::Option<aws_smithy_http::byte_stream::ByteStream>`
              found enum `std::option::Option<aws_smithy_types::Blob>`

However, if I add @httpPayload above the line output: StreamingBlob, then it builds fine.

I don't see anything in the Smithy spec that says streaming blobs must also be bound with @httpPayload. I would have assumed that adding @httpPayload would be superfluous; I had always thought that blob @streaming would imply that the data is automatically streamed over the HTTP body. However, I can't reconcile that idea with the example that is featured in the Smithy docs:

operation StreamingOperation {
    input: StreamingOperationInput,
    output: StreamingOperationOutput,
}

@input
structure StreamingOperationInput {}

@output
structure StreamingOperationOutput {
    @required
    streamId: String
    output: StreamingBlob,
}

@streaming
blob StreamingBlob

Here, it would seem like @streaming should be strictly interpreted as simply "the data could be very large and thus should not be stored in memory or that the size is unknown at the start of the request" as per the spec, without ascribing any special semantics as to how the data is sent over HTTP, since the body also contains a streamId string.

This last example from the Smithy docs also fails to compile in smithy-rs, but is accepted by Smithy CLI.

[david-perez]

Turns out the model should be rejected by Smithy and the Smithy spec should be updated.

The rule that needs to be enforced is "if protocol supports httpPayload, then streaming MUST be paired with httpPayload".

smithy-lang/smithy#1075

[jdisanti]

It looks like the linked Smithy issue was resolved a while ago, so I think this validation was added.