oxidecomputer / oxidecomputer/typify
Uninformative error on self-conflicting types
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 898
- Forks
- 114
- Avg merge
- 4h 18m
- Merged PRs (30d)
- 14
Description
I used the following OpenAPI schema:
{
"components": {
"schemas": {
"Foo": {
"allOf": [
{
"$ref": "#/components/schemas/Bar"
},
{
"properties": {
"value": {
"type": "string"
}
}
}
],
"required": [
"value"
]
},
"Bar": {
"properties": {
"value": {
"type": "object"
}
}
}
}
},
"info": {
"title": "",
"version": "1.0"
},
"openapi": "3.0.1",
"paths": {
}
}
I expected an error saying that the type of value in Foo was ambiguous. I got:
thread 'main' panicked at /Users/[my_user]/.cargo/registry/src/index.crates.io-6f17d22bba15001f/typify-impl-0.0.15/src/merge.rs:265:70:
called `Result::unwrap()` on an `Err` value: ()
It seems silly in this example, but the original schema was 10000 lines long, so it was quite tedious to isolate the issue.
Meta
Progenitor version used was 0.5.0.
I used a build.rs file to invoke progenitor.
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
Start by reproducing the schema from the issue through a build.rs invocation, then inspect the merge logic reported in typify-impl/src/merge.rs around the failing unwrap. The fix is done when conflicting property types produce an informative error instead of a panic, with coverage for this self-conflicting allOf case.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- openapi, rust
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100