search

bartongroup / slivka

http://bartongroup.github.io/slivka/
Apache License 2.0
7 stars 3 forks source link

Choice parameters accept a "key" as input but presents the matching "value" #135

Open warownia1 opened 7 months ago

warownia1 commented 7 months ago

Quote from the conversation on gitter:

A little subtlety that's caused me a bit of head-scratching. Let me know if you'd prefer I went straight to Github with this, but seems easier to discuss here.

For parameters which have "choices"... Slivka service definitions have two representations of each choice. Since they're represented as a "dictionary" in the service definition, let's call these key and value. If I request the service information from the /api/services/ endpoint, I just see the "keys" part of the dictionary. So the implication here is that Slivka clients should be using those, and the "value" part (which is what actually gets passed to the underlying command-line tool) is hidden away.

When I submit jobs, I always use the "key" (although... it looks like using the "value" in a submission is also supported as well, which opens some interesting possibilties). However, there's a bit of an oddity here: in the response from the submission (and also, in any subsequence job status checks) you see the value instead. This seems to be the only scenario where an API client gets to see the value.

From the point of view of writing a robust UI, this is a little problematic. For instance, I can't take a job ID and reliably work out what was submitted, since I'm seeing the value rather than the key.

Is there any chance this might change in future (either by showing "choice" parameter values by key, rather than value, in the API responses, or perhaps by exposing both key and value in the service metadata?)

There are definitely a few odd corder cases relating to handling of choices, due to the API accepting both "keys" and "values". For instance, consider the following (shamelessly modelled on example.service.yaml):

choices:
    alpha: A
    bravo: B
    charlie: C
    delta: D
    C: D

So submitting "B" will be interpretted as "B", but submitting "C" will be interpretted as "D"!. Obviously, a very contrived example and not something you'd do deliberately, but in more complex lists of options I could see myself doing something equivalent by accident....