Semantics of constrained event streams for the server

[david-perez]

What should a server do upon receiving an event message in an event stream that does not satisfy the modeled constraint traits?

For example, with the following model, say a client sends an event message with messageContent set to a string of length 1.

@streaming
union Event {
    regularMessage: EventStreamRegularMessage,
    errorMessage: EventStreamErrorMessage,
}

structure EventStreamRegularMessage {
    messageContent: LengthString
}

@error("server")
structure EventStreamErrorMessage {
    messageContent: LengthString
}

@length(min: 2, max: 69)
string LengthString

Should the server:

• ignore the constraints and hand it to the application code?
• swallow the message and not hand it to the application code?
• terminate the event stream?
• signal to the application code an invalid message was received? How?

[ptrucks]

My team just ran into this issue when trying to generate the Rust server SDK for a shared model. Interestingly, the Java and TypeScript code generators did not complain about the constraints applied to streamed events, but the Rust generator complained with a link to this issue.

Is there a reason to treat constraint errors for an event fundamentally different from deserialization errors for events?

Let's take for example:

operation GetMessages {
    input: GetMessageInput,
   output: GetMessageOutput,
}

@input
structure GetMessageInput {}

@output
structure GetMessageOutput {
   @httpPayload
   events: MessageEvents
}

@streaming
union MessageEvents {
    message: Message
}

structure Message {
    @length(min: 5)
    message: String
}

It seems intuitive to treat a message JSON which fails the @length constraint, e.g.:

{"message":"msg"}

in a similar way as

{"message":1337}

which also breaks the API contract because the type is number instead of string.

At the moment the second kind of check happens implicitly during deserialization, while the first kind is made impossible.

It is especially unfortunate that this also prevents enum types from appearing as event members, the removal of which affects generated client code.

[mtdowling]

These should be validated, and the server should close the event stream. Ideally it sends back a Validation error just like with other normal operations, and if you don't have a modeled error of this type, send back a generic protocol error.