description is accepted on #[asyncapi_channel(...)] and #[asyncapi_operation(...)], parsed into the meta structs, and then silently discarded — it never reaches the generated document.
Cause
ChannelMeta.description (asyncapi-rust-codegen/src/asyncapi_spec_attrs.rs:70) and OperationMeta.description (:92) are both populated by their parsers, but the corresponding models have no field to hold it:
Channel (asyncapi-rust-models/src/lib.rs:336) has only address, messages, parametersOperation (:597) has only action, channel, messages, bindings
so the codegen at asyncapi-rust-codegen/src/lib.rs:977 and :1132 never emits it.
Repro
#[derive(AsyncApi)]
#[asyncapi(title = "Probe", version = "1.0.0")]
#[asyncapi_channel(name = "chat", address = "/chat", description = "CHANNEL DESC")]
#[asyncapi_operation(name = "send", action = "send", channel = "chat", description = "OP DESC", messages = [Msg])]
pub struct Api;
Neither string appears anywhere in Api::asyncapi_spec(). No warning, no error.
Expected
Both should emit description on the respective object — AsyncAPI 3.0 allows it on both the Channel Object and the Operation Object.
Note the attribute is not currently listed in the documented attributes for either macro, so this is a silently-ignored input rather than a documented feature that regressed. Rejecting it would also be defensible, but emitting it is clearly the intent given the parsers already collect it.
descriptionis accepted on#[asyncapi_channel(...)]and#[asyncapi_operation(...)], parsed into the meta structs, and then silently discarded — it never reaches the generated document.Cause
ChannelMeta.description(asyncapi-rust-codegen/src/asyncapi_spec_attrs.rs:70) andOperationMeta.description(:92) are both populated by their parsers, but the corresponding models have no field to hold it:Channel(asyncapi-rust-models/src/lib.rs:336) has onlyaddress,messages,parametersOperation(:597) has onlyaction,channel,messages,bindingsso the codegen at
asyncapi-rust-codegen/src/lib.rs:977and:1132never emits it.Repro
Neither string appears anywhere in
Api::asyncapi_spec(). No warning, no error.Expected
Both should emit
descriptionon the respective object — AsyncAPI 3.0 allows it on both the Channel Object and the Operation Object.Note the attribute is not currently listed in the documented attributes for either macro, so this is a silently-ignored input rather than a documented feature that regressed. Rejecting it would also be defensible, but emitting it is clearly the intent given the parsers already collect it.