You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
swagger.json didn't match API output for spec.templates[0].dag.tasks[1].withItems. The swagger spec describeswithItems as an array of Item, but instead the array items can be numbers, booleans, strings, arbitrary objects, or arrays of these same types (except the nested arrays may contain any values, including nulls, if I'm reading the code correctly).
Aside: Downstream, this causes issues for at least the Java client. I've written an issue for argo-client-gen. Unfortunately, I don't think fixing swagger.json will fix the client (at least not if the fix relies on Swagger's oneOf feature, which I think it probably will).
How to reproduce it (as minimally and precisely as possible):
Item, when expressed as an array, may contain elements of type ItemValue. That type also has a custom marshaller/unmarshaller, so it should probably be modified in swagger.json as well.
I think withItems should be overridden in _primary.swagger.json to use Swagger's oneOf to express the possible types. One of the oneOf types would probably be "array of ItemValues", so ItemValue should probably also be overridden. I suspect Item will simply be orphaned.
If the argo-client-gen solution involves simply overriding withItem's type in the openapi-generator arguments, the type info should probably be in a synthetic, named type rather than directly in the withItem block.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Checklist:
What happened:
swagger.json didn't match API output for
spec.templates[0].dag.tasks[1].withItems
. The swagger spec describeswithItems
as an array ofItem
, but instead the array items can be numbers, booleans, strings, arbitrary objects, or arrays of these same types (except the nested arrays may contain any values, including nulls, if I'm reading the code correctly).Aside: Downstream, this causes issues for at least the Java client. I've written an issue for argo-client-gen. Unfortunately, I don't think fixing swagger.json will fix the client (at least not if the fix relies on Swagger's
oneOf
feature, which I think it probably will).How to reproduce it (as minimally and precisely as possible):
argo submit https://raw.githubusercontent.com/argoproj/argo/master/examples/loops-dag.yaml -n argo
Then hit
/api/v1/workflows/argo
on your Argo server.Search for "withItems", and you'll find that the array contains strings.
Anything else we need to know?:
Item
has a custom marshaller/unmarshaller, which is why swagger.json doesn't match the API output.Item
, when expressed as an array, may contain elements of typeItemValue
. That type also has a custom marshaller/unmarshaller, so it should probably be modified in swagger.json as well.I think
withItems
should be overridden in _primary.swagger.json to use Swagger'soneOf
to express the possible types. One of theoneOf
types would probably be "array ofItemValue
s", soItemValue
should probably also be overridden. I suspectItem
will simply be orphaned.If the argo-client-gen solution involves simply overriding
withItem
's type in the openapi-generator arguments, the type info should probably be in a synthetic, named type rather than directly in thewithItem
block.Environment:
Message from the maintainers:
If you are impacted by this bug please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.
The text was updated successfully, but these errors were encountered: