A variety of improvements around tool parameter modeling. #18952
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This contains tests, fixes, and refactorings of the tool parameter models aimed at enabling two applications/APIs - these applications are a tool landing API and the tool request API. Those APIs and corresponding runtimes are not included here but can be found in the structured tool state branch (tool request API and tool landing API).
The bulk of the enhancements around enabling tool landing are found in a single commit titled "models for tool landing request state...". This introduces two new tool state representation types and wide variety of parameter specification tests that describe how the API will work and how models will be stored. The API will consume tool state with the representation type "landing_request" and will store the representation "landing_request_internal" in the database. The internal version is the decoded version of that tool state. The idea behind the landing API is that essentially everything is optional - external entities could for instance host a collection of FASTA files and provide links to tools to align against these for instance - all the parameters but the database would be deferred to the users discretion. The parameters that are provided though will be validated.
The remainder of the commits are a collection of things that make more confident were not doing damage with the tool request API. Part of that effort is having a fully expanded representation of the tool state that describes something pretty close to what we feed the wrappers - defaults expanded out, no absent conditionals, etc... That effort resulting in me writing lots of API tests to describe how the current API works so we don't regress it, implementing validation of static parameter validators so we can mimic some of the runtime behavior of the tools and write stronger upfront validation of the requests, etc...
How to test the changes?
(Select all options that apply)
License