Cannot Generate DefectDojo API

[thekief]

I'm currently trying to generate the DefectDojo API and it fails with the following log message:

   Compiling progenitor-client v0.11.2 (https://github.com/oxidecomputer/progenitor#73fa5d3f)
   Compiling dd-client v0.1.0 (<project path>/dd-client)
error: failed to run custom build command for `dd-client v0.1.0 (<project path>/dd-client)`

Caused by:
  process didn't exit successfully: `<project path>/dd-client/target/debug/build/dd-client-ad5576f2df920089/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=resources/openapi.json

  --- stderr

  thread 'main' (5040479) panicked at <home path>/.cargo/git/checkouts/progenitor-c11fbe48354ec7ff/73fa5d3/progenitor-impl/src/method.rs:2048:23:
  not yet implemented: more media types than expected for announcements_update: 3
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The offending snippet for this issue is here:

			"post": {
				"operationId": "announcements_create",
				"tags": ["announcements"],
				"requestBody": {
					"content": {
						"application/json": {
							"schema": { "$ref": "#/components/schemas/AnnouncementRequest" }
						},
						"application/x-www-form-urlencoded": {
							"schema": { "$ref": "#/components/schemas/AnnouncementRequest" }
						},
						"multipart/form-data": {
							"schema": { "$ref": "#/components/schemas/AnnouncementRequest" }
						}
					}
				},

What's the reason behind the restriction here?

progenitor/progenitor-impl/src/method.rs

Lines 2045 to 2053 in 73fa5d3

	let (content_str, media_type) = match (body.content.first(), body.content.len()) {
	(None, _) => return Ok(None),
	(Some(first), 1) => first,
	(_, n) => todo!(
	"more media types than expected for {}: {}",
	operation.operation_id.as_ref().unwrap(),
	n,
	),
	};

Is there any plan to implement this any time soon?

[ahl]

No imminent plans, but it seems like we could probably just look for one of the known media types and ignore ones we don't intend to use for the request body.

There are situations where a consumer might want to be able to affect the media type that is sent for an operation... which is--I think--why this code is written as it is. For example, consider this snipped from the github API:

        "requestBody": {
          "content": {
            "text/plain": {
              "schema": {
                "type": "string"
              }
            },
            "text/x-markdown": {
              "schema": {
                "type": "string"
              }
            }
          }
        },

In this situation one might want to have an enum to describe the intended media type since it impact the interpretation e.g. of the string that's sent. However, it seems like there's probably some pragmatic, simple step we could take to accommodate the use case you describe.