Accept 200 and 201 when re-associating a changed condition node

[blaipr]

Summary

When an existing condition edge's parameters change, condition_nodes disassociates the edge and posts it again. That second post set changed only on a 204, and let a 200 or a 201 through without setting it:

response = module.post_endpoint(condition_endpoint, **{'data': dc})
if response['status_code'] == 204:
    module.json_output['changed'] = True
elif response['status_code'] not in [200, 201, 204]:
    module.fail_json(...)

The new-association path a few lines below already accepts all three, so the two halves of the same operation disagreed on what a successful association looks like.

No run reports the wrong result today: the disassociate that runs first returns 204 and sets the flag before the re-association is attempted, so the missing case is unreachable while the API keeps returning 204 for these relation endpoints. This makes the two paths agree rather than fixing an observable failure, which is why the changelog fragment lands under minor_changes rather than bugfixes.

Type of Change

• Bug fix
• New feature or enhancement
• Breaking change
• Documentation / tooling

Component

workflow_job_template_node, the condition_nodes re-association path.

Checklist

• Sanity tests pass (ansible-test sanity, ansible-core 2.21.1 on Python 3.12)
• Linting passes (ruff, yamllint, ansible-lint)
• Changelog fragment added (if user-facing change)
• Documentation updated (if applicable)

[ciq-it-service-account]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[Copilot]

Pull request overview

Aligns the workflow_job_template_node module’s condition_nodes re-association behavior with the existing “new association” path so successful association responses (200/201/204) are handled consistently and reflected in Ansible’s changed result.

Changes:

• Treat 200/201/204 as successful status codes when re-associating a condition edge whose parameters changed, and mark changed=True in those cases.
• Add a changelog fragment documenting the alignment and rationale.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
plugins/modules/workflow_job_template_node.py	Updates the condition_nodes re-association status-code handling to match the new-association logic.
changelogs/fragments/fix-condition-node-reassociate-changed.yml	Documents the behavior change under minor_changes.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[blaipr]

Copilot is right on this one, so it is fixed in 77970a7.

The re-association path read the disassociate response only to set changed on a 204, and anything else fell straight through to the post_endpoint that follows. A 4xx or a 5xx there was silently discarded and the module carried on re-associating an edge the controller had just refused to remove.

                     if response['status_code'] == 204:
                         module.json_output['changed'] = True
+                    else:
+                        module.fail_json(
+                            msg=f"Failed to disassociate condition node {response['json'].get('detail', response['json'])}"
+                        )
                     response = module.post_endpoint(condition_endpoint, **{'data': dc})

That is the same shape as the "Disassociate removed condition nodes" block above it, which has always failed fast, so the two disassociates now read identically and the two associates already did after the first commit here.

The changelog fragment gains a bugfixes entry for it, since a run that used to continue past a failed disassociate will now stop.

ruff check plugins/, yamllint and antsibull-changelog lint are clean.