oxidecomputer / oxidecomputer/progenitor
CLI generation fails for array-like and object-like query parameters
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 1k
- Forks
- 136
- Avg merge
- 8h 36m
- Merged PRs (30d)
- 14
Description
#1017 added support for query parameters that serialize into maps or arrays (in addition to ones that serialize into strings), but this didn't consider how this might be handled for CLI generation. In generated CLIs, query parameters become CLI flags and are handled with code like this:
::clap::Arg::new("id")
.long("id")
.value_parser(::clap::value_parser!(types::GetThingOrThingsId))
.required(false),
...
if let Some(value) = matches.get_one::<types::GetThingOrThingsId>("id") {
request = request.id(value.clone());
}
This is going to require some additional sophistication.
For a query parameter that's an array, we'll need something like this:
::clap::Arg::new("id")
.long("id")
.value_parser(::clap::value_parser!(String))
.action(::clap::ArgAction::Append)
.required(false),
...
if let Some(value) = matches.get_many("id") {
request = request.id(value.copied().collect());
}
For map/object types we'll need to handle them a bit like we do body parameters.
This gets worse for untagged enums e.g. a type like this:
#[serde(untagged)]
pub enum GetThingOrThingsId {
Variant0(::std::string::String),
Variant1(::std::vec::Vec<::std::string::String>),
}
... and still worse if we consider heterogeneous enums. For example, what parameter would we provide to clap::value_parser!?
Imagine a query parameter that's either a single number or an array of strings. That seems pretty hard to model with clap... and--fortunately--also an extremely contrived API!
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Trace the generated CLI handling for query parameters and compare it with the existing body-parameter handling mentioned in the issue. Determine how array and map/object parameters should be represented in clap, then assess the behavior for untagged and heterogeneous enums; done means generated CLIs can handle the supported query shapes without invalid value parsing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- openapi, rust
- Domain
- api, cli, tooling
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100