Fix PsrpOperator option checks

[1fanwang]

command, powershell and cmdlet are mutually exclusive, and arguments / parameters are only valid alongside the latter two. All five are template fields, and every check was written as a truthiness test:

• exactly_one was handed a set literal, so passing the same value to two options deduped to one and passed validation.
• A provided-but-empty option (command="", arguments=[]) read as absent, so valid combinations were rejected and invalid ones accepted.
• execute() dispatched on truthiness too, so a command that renders to "" fell through and ran as powershell.

The checks stay in __init__. Per #70505 the constructor is the only place that can answer "was this argument passed?", so they are rewritten with the is None polarity the docs now prescribe. Only the dispatch in execute() moves to is not None, where the rendered value is finally known.

The cmdlet-derived task_id default is out of scope here. Dropping it changes task identity, so it goes in a follow-up rather than riding along with a validation fix. That also keeps this one unblocked: #70656 made the same validation fix without the task_id change and was closed in favour of this PR, so the burn-down now waits on this landing.

PsrpOperator therefore stays on the validate-operators-init exemption list, since the hook flags the task_id derivation rather than these checks. Restoring that entry also resolved the merge conflict, which was only ever that one line.

related: #70296, #70505

Testing Done

#	Scenario	Result
1	New/changed cases against the pre-fix operator	6 fail, 3 pass (the 3 are the pre-existing guards this must not regress)
2	Full operator suite after the fix	42 passed

Raw logs

1. Red — new tests run against upstream/main's psrp.py:

$ git show upstream/main:providers/.../operators/psrp.py > providers/.../operators/psrp.py
$ uv run --project providers/microsoft/psrp pytest providers/microsoft/psrp/tests/unit/microsoft/psrp/operators/test_psrp.py \
    -q -k "invalid_option_combination or empty_option_counts or dispatches_as_command"
E   assert equals failed
E      -(None, )                   +(
E                                +  "cmd.exe /c @'\n\n'@",
E                                +)
=========================== short test summary info ============================
FAILED ...::test_invalid_option_combination[two-options-one-empty]
FAILED ...::test_invalid_option_combination[two-equal-options]
FAILED ...::test_empty_option_counts_as_provided[empty-command]
FAILED ...::test_empty_option_counts_as_provided[arguments]
FAILED ...::test_empty_option_counts_as_provided[parameters]
FAILED ...::test_command_rendering_to_empty_dispatches_as_command
============ 6 failed, 3 passed, 33 deselected, 1 warning in 15.40s ============

2. Green — full suite on the fixed operator:

$ uv run --project providers/microsoft/psrp pytest providers/microsoft/psrp/tests/unit/microsoft/psrp/operators/test_psrp.py -q
======================== 42 passed, 1 warning in 3.44s =========================

[potiuk]

Thanks — the core fix is correct and worth having. args = {command, powershell, cmdlet} built a set, so equal values collapsed into one entry, and exactly_one then counted truthiness rather than presence — meaning an empty-string command read as "not provided". Switching to explicit is not None checks fixes both problems, and carrying the same correction into execute() keeps it consistent.

One blocking concern: this PR also removes kwargs.setdefault("task_id", cmdlet), so a Dag that relied on the cmdlet supplying the task_id now gets a different task_id. That changes task identity — history, logs, XComs and UI links all key off it — so it isn't a refactor, it's a breaking change for those users.

Please either:

1. split the task_id removal into its own PR so the (uncontroversial) validation fix can land immediately, or
2. keep it here but add a newsfragment in airflow-core/newsfragments/ explaining that PsrpOperator no longer defaults task_id to cmdlet and what users must do — plus a line in the provider changelog.

For context: #70656 makes the same validation fix without the task_id change. It was opened six days after this one, so I'm closing it in favour of this PR — which means the validation fix now depends on this one moving. Option 1 would unblock it fastest.

These are judgement calls rather than mechanical fixes — I'd welcome your own reasoning in reply. My review was AI-assisted and shouldn't be treated as settled.

---

Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting

[potiuk]

This docstring edit is the visible half of the behaviour change — dropping "Also used as the default value for task_id" alongside removing the setdefault.

Documenting it here is right, but a docstring is not where users find out that their task_ids changed. That needs the newsfragment/changelog entry described in the review body.

---

Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting

[1fanwang]

Reverted with the setdefault , so the docstring documents the task_id default again

[1fanwang]

Thanks — the core fix is correct and worth having. args = {command, powershell, cmdlet} built a set, so equal values collapsed into one entry, and exactly_one then counted truthiness rather than presence — meaning an empty-string command read as "not provided". Switching to explicit is not None checks fixes both problems, and carrying the same correction into execute() keeps it consistent.

One blocking concern: this PR also removes kwargs.setdefault("task_id", cmdlet), so a Dag that relied on the cmdlet supplying the task_id now gets a different task_id. That changes task identity — history, logs, XComs and UI links all key off it — so it isn't a refactor, it's a breaking change for those users.

Please either:

1. split the task_id removal into its own PR so the (uncontroversial) validation fix can land immediately, or
2. keep it here but add a newsfragment in airflow-core/newsfragments/ explaining that PsrpOperator no longer defaults task_id to cmdlet and what users must do — plus a line in the provider changelog.

For context: #70656 makes the same validation fix without the task_id change. It was opened six days after this one, so I'm closing it in favour of this PR — which means the validation fix now depends on this one moving. Option 1 would unblock it fastest.

These are judgement calls rather than mechanical fixes — I'd welcome your own reasoning in reply. My review was AI-assisted and shouldn't be treated as settled.

Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting

thanks! went with option 1, so this PR is validation-only now.