-
Notifications
You must be signed in to change notification settings - Fork 107
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
JSON parsing for inline scripts needs custom processing in certain situations (fan-out/in) #1146
Closed
2 of 6 tasks
Comments
ljyanesm
changed the title
Nested fan-in json parsing is awkward
JSON parsing can be awkward in certain situations
Aug 5, 2024
elliotgunton
changed the title
JSON parsing can be awkward in certain situations
JSON parsing for Inline scripts needs custom processing in certain situations (fan-out/in)
Aug 21, 2024
elliotgunton
changed the title
JSON parsing for Inline scripts needs custom processing in certain situations (fan-out/in)
JSON parsing for inline scripts needs custom processing in certain situations (fan-out/in)
Aug 21, 2024
Hey @ljyanesm - turns out this was a bug upstream - argoproj/argo-workflows#13510 - with a PR that's now been merged! I think I'll leave this open until it's actually released |
Thank you @elliotgunton! This is really great, looking forward to these changes. |
Fix was released in Argo Workflows 3.5.11! 🚀 |
This was referenced Oct 1, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Pre-bug-report checklist
1. This bug can be reproduced using pure Argo YAML
If yes, it is more likely to be an Argo bug unrelated to Hera. Please double check before submitting an issue to Hera.
2. This bug occurs in Hera when...
Handling JSON serialised objects generated by Argo Worfklows using the
json.loads
method included at the beginning of allScripts
Bug report
Describe the bug
A clear and concise description of what the bug is:
When using nested fan-in patterns on
Script
tasks the json parsing code introduced to handle Argo parameters can fail, see:Unfortunately this results in a broken behaviour if one uses a nested fan-out and fan-in pattern. In these cases the Argo YAML generated isn’t aware of the multiple levels of serialisation, so one ends up with a top level JSON object that contains JSON that has been stringified.
For example consider a nested fan-out fan-in with 2 items and 2 sub items from which one would like to receive the data structure below back during the final fan-in.
[["item_0_subitem_0", "item_0_subitem_1"], ["item_1_subitem_0", "item_1_subitem_1"]]
In practise one receives the two item list below, where each item is a stringified version of the nested list.
["["\"item_0_subitem_0\"","\"item_0_subitem_1\""]","["\"item_1_subitem_0\"","\"item_1_subitem_1\""]"]
The defect is that the content has been serialised twice, but only deserialised once. To fix this one needs a way to deserialise, then iterate over all the items in the data structure and deserialise those.
Error log if applicable:
There is no immediate error apart from the inconvenience of having to handle a partially deserialised JSON object.
To Reproduce
Full Hera code to reproduce the bug:
Expected behavior
A clear and concise description of what you expected to happen:
The input object to
fan_in
should be a valid python object without any remanent JSON strings within.Environment
Additional context
Please notice the
decode(jo)
which could be used alternatively to the originaljson.loads(r'''{{inputs.parameters.in_param}}'''
to handle this issue.The text was updated successfully, but these errors were encountered: