Some more broken endpoints, and not a few
Closed this issue · 5 comments
Autogenerated APIs are truly a godsend... All I'm doing is just calling them in an empty binary crate that includes only podman-rest-client and tokio.
This started by just me trying to use system_ping or system_info_libpod as a means to validate if the connection to Podman actually works by pinging Podman, and neither worked, so I dug deeper and these are the results of me just calling randomly picked endpoints:
system_ping():thread 'main' panicked at src/main.rs:6:37: called `Result::unwrap()` on an `Err` value: SerdeJsonPath(Error { path: Path { segments: [] }, original: Error("expected value", line: 1, column: 1) })system_info_libpod():thread 'main' panicked at src/main.rs:9:44: called `Result::unwrap()` on an `Err` value: SerdeJsonPath(Error { path: Path { segments: [Map { key: "registries" }, Map { key: "search" }] }, original: Error("invalid type: sequence, expected unit", line: 1, column: 3281) })image_search()when calling with term=debian:thread 'main' panicked at src/main.rs:18:10: called `Result::unwrap()` on an `Err` value: SerdeJsonPath(Error { path: Path { segments: [Seq { index: 0 }] }, original: Error("invalid type: map, expected a string", line: 1, column: 1) })image_search_libpod()when calling with term=debian:thread 'main' panicked at src/main.rs:18:10: called `Result::unwrap()` on an `Err` value: SerdeJsonPath(Error { path: Path { segments: [Seq { index: 0 }] }, original: Error("invalid type: map, expected a string", line: 1, column: 1) })
There are probably more of these, I may extend the list as I poke around further. If only we had Kiota for Rust...
I think we need to treat any value in a hashmap as nullable. I stubbornly refused to do so, thinking I could spot fix the issues and eventually report them upstream to the podman. But it's too pervasive a problem. I'm not sure why go or podman sticks nil in all these hashmaps instead of leaving them blank.
Auto generated clients are normally great! I've had a lot of success with swagger/open-api clients generated from python, java, and node servers. There is something about podman or go-swagger in particular that seems like a real mess here.
Turns out I was wrong about this having anything to do with nils and HashMaps.
The image search endpoints just have the wrong spec. It says it returns a single RegistrySearchResponse instead of an array of RegistrySearchResponse. I reported the issue upstream containers/podman#23741 and just edited the local copy of the swagger file to be correct.
The system ping endpoint is "fixed" too. This one was my fault as it was not handling text/plain responses correctly and treating the response like JSON. One remaining issue though is that it looks like this endpoint is meant to communicate through header responses, and the library is not exposing those headers from the response. I guess the generator should notice the header bits mentioned in the spec and present those in the return value as well. Is that something that's useful/important to you?
Release v0.12.5 has the fixes.
It will never not be baffling to me how Go designers thought having no null safety in a greenfield language was a good idea. And yet everyone seems to adore Go. Thanks for the fixes!