Not getting status code 200 generated when using actix-multiresponse

[Tobias de Bruijn]

Hi,

I'm encountering some strange behavior when using actix-multiresponse, with the paperclip feature enabled.

My route's function looks like this:

#[api_v2_operation(tags(v1, sensor_alert))]
pub async fn get(data: WebData, path: web::Path<Path>, session: Session) -> WebResult<Payload<proto::Alert>> { ... }

with proto::Alert being derived from a .proto file using prost:

#[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))]
#[cfg_attr(feature = "paperclip", derive(paperclip::actix::Apiv2Schema))]
#[derive(Clone, PartialEq, ::prost::Message)]
pub struct Alert {
    #[prost(uint32, tag="1")]
    pub id: u32,
    ...
}

The paperclip and serde features are enabled for the proto crate here, so Apiv2Schema is derived.

The Payload struct looks like:

pub struct Payload<T: 'static + Default + Clone + PaperclipSupport>(pub T);

#[cfg(feature = "paperclip")]
pub trait PaperclipSupport: paperclip::v2::schema::Apiv2Schema + paperclip::actix::OperationModifier {}

It too has Apiv2Schema derived.

However, the generated spec omits the response entirely:

      responses:
        '400':
          description: Bad Request
        '401':
          description: Unauthorized
        '409':
          description: Conflict
        '429':
          description: Too Many Requests
        '500':
          description: Internal Server Error

I'm not getting any compiler errors, warnings or runtime warnings of any kind.

Environment

• cargo: cargo 1.62.0-beta.2 (3f052d8ee 2022-05-12)
• target: x86_64-unknown-linux-gnu
• paperclip: 0.7.0
• actix-web: 4.1.0
• actix-multiresponse: 0.1.1
• prost: 0.9.0

[Tobias de Bruijn]

Looking in the generated spec, I do see something for Payload<T>, though it seems to ignore generics (is Apiv2Schema implemented incorrect for Payload<T>?):

  _Payload<>:
    description: |-
      Payload wrapper which facilitates the (de)serialization.
       This type can be used as both the request and response payload type.

       The proper format is chosen based on the `Content-Type` and `Accept` headers.
       When deserializing only the `Content-Type` header is used.
       When serializing, the `Accept` header is checked first, if it is missing
       the `Content-Type` header will be used. If both are missing the payload will
       default to `JSON`.

       # Errors

       When the `Content-Type` header is not provided in the request or is invalid, this will return a HTTP 400 error.
       If the `Content-Type` header, or `Accept` header is invalid when responding this will return a HTTP 400 error,
       however this is *not* done if both headers are missing on response.

       # Panics

       If during serializing no format is enabled
    type: object
    properties:
      organizations:
        type: array
        items:
          type: object
          properties:
            description:
              type: string
            id:
              type: integer
              format: int32
            name:
              type: string
          required:
            - id
            - name
    required:
      - organizations

Though the definition is never used.