Generation fails with combined empty + non-empty error responses

If an API spec has an empty and non-empty response option, then the assertion in response_types.len() <= 1 fails and the API generation fails (shown below). The assertion appears in method.rs.

error: proc macro panicked
  --> src/main.rs:13:5
   |
13 |     generate_api!("openapi.yaml");
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: message: assertion failed: response_types.len() <= 1

The error seems to occur regardless of what the non-empty response is and what content type is used. The issue also only seems to occur if both response codes are error or both are success codes. For example, the below spec compiles, but it will fail to compile if the status codes are changed to both be 4xx/5xx or 2xx. I reproduced the issue with v0.11.0 and the most recent commit at time of writing (link).

openapi: 3.0.0
info:
  title: Example Service
  version: 1.2.0
paths:
  /:
    get:
      operationId: test
      responses:
        '200':
          description: Example description
          content:
            application/json:
              schema:
                type: string
        '404':
          description: The server cannot find the requested resource.

I have tested the following combinations of status codes. The order of the status codes does not appear to matter.
Fails:

• 200, 204
• 200, 299
• 400, 404
• 400, 499
• 401, 404
• 404, 500
• 500, 599

Succeeds:

• 100, 199
• 100, 200
• 200, 302
• 200, 404
• 300, 399
• 312, 321

For a real-world example of this behavior, I originally encountered this issue with the ZeroTier API spec. The route /controller/network/{network_id} returns an empty JSON object with status code 401 and nothing with a status code 404. It should be noted that the current API spec that I previously linked listed 404 responses as returning an empty JSON object. The API spec is wrong (404 responses are empty), but correcting the spec makes this error appear.

Start with the assertion in progenitor-impl/src/method.rs around line 1211 and reproduce the failure using the minimal OpenAPI specification in the issue. Compare generation for combined empty and non-empty responses across the listed status-code combinations. Done means valid specifications with these response combinations generate successfully without the proc-macro assertion.