Fixes #32047 - Match proxy actions using task_id #617
Conversation
app/lib/actions/proxy_action.rb
Outdated
| action['class'] == proxy_action_name || action.fetch('input', {})['proxy_operation_name'] == proxy_operation_name | ||
| end | ||
| proxy_data.fetch('output', {}) | ||
| response['actions'].detect { |action| action['input']['task_id'] == task.id } |
There was a problem hiding this comment.
given how action.fetch('input', {}) was used defensively before, are we sure action['input'] is always a hash? or should we also write that more defensively?
There was a problem hiding this comment.
If there's an action there should be an input and if there's an input it is a hash. Otoh playing it safe is almost free so I can do it that way
When we're retrieving outputs of proxy actions we get back a serialized execution plan, walk its actions and look for an action with either expected action_class or operation name. This is somewhat flaky. With this change we only check one field in the actions' input and that is task_id. First action found with matching value is considered the source of output for the current task.
adamruzicka
force-pushed
the
proxy-action-matching
branch
from
e7467ad
to
5e2031c
Compare
|
FTR, I would consider this temporary. It will most likely change when we start retrieving outputs in batches |
|
This probably caused the regression that for Ansible, I see |
|
To be honest I'd be surprised if this was the cause as this doesn't really change how we access the data. Edit: What I wrote before still holds, but the return type is different. |
When we're retrieving outputs of proxy actions we get back a serialized
execution plan, walk its actions and look for an action with either expected
action_class or operation name. This is somewhat flaky.
With this change we only check one field in the actions' input and that is
task_id. First action found with matching value is considered the source of
output for the current task.