Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to autogeneration of the specification. #209

Open
claymcleod opened this issue Sep 10, 2024 · 2 comments
Open

Switch to autogeneration of the specification. #209

claymcleod opened this issue Sep 10, 2024 · 2 comments
Milestone

Comments

@claymcleod
Copy link

Manual editing of the YAML has led to some things that make the OpenAPI specification far less useful than it could otherwise be. For example, when retrieving a tesTask from the GET /task/{id} endpoint, the fields that are returned are dependent on the view query parameter. However, if you look at the definition of the schema for tesTask (which the OpenAPI specification indicates is the only valid response returned from that endpoint), it requires that the executors key is always present. This is actually not the case— in fact, the default behavior of the specification only return the id and state keys within that object.

This, in turn, makes it very difficult to use off the shelf (for example, no libraries that autogenerate bindings using the OpenAPI spec can be used).

For what it's worth, we auto-generated the specification using utoipa during the design of the CCDI Federation API, and it was really a pleasant experience (and also had the side benefit of having a Rust implementation that worked right out of the box). There are probably other ways to do it, just giving an example of where I've done this with success.

@uniqueg
Copy link
Contributor

uniqueg commented Sep 20, 2024

I could swear that I wrote an issue for the inconsistent model definition for tesTask with respect to executors a long time ago, but I don't find it anymore - neither in the open, nor the closed issues. Any idea why that could be, @kellrott?

On the topic: Might well be worth to check out for TES 2.0 👍

@vsmalladi
Copy link
Contributor

Ya i think its worth maybe having a meeting next week to talk about TES 2.0

@vsmalladi vsmalladi added this to the 2.0 milestone Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants