Validate trigger events in Openai deferrable tasks

[takayoshi-makabe]

OpenAITriggerBatchOperator.execute_complete used the trigger event without validating it, branching deny-list style (only status == "error" raised, everything else succeeded):

• cancelled was marked SUCCESS: the provider's own OpenAIBatchTrigger emits {"status": "cancelled"} when the batch is cancelled while the task is deferred, but only error raised — so the task went green with no results. The non-deferrable path (OpenAIHook.wait_for_batch) has raised for CANCELLED/CANCELLING since feat(providers/openai): support batch api in hook/operator/trigger #41554, so the two modes of the same operator disagreed.
• event=None: crashed with an opaque TypeError: 'NoneType' object is not subscriptable.
• Unrecognised status (triggerer/worker version skew, custom trigger): fell through into the success path.

Same fix shape as the anthropic provider in #69379: a validate_execute_complete_event() helper plus allow-list branching (status != "success" raises).

Also fixes a missing else in OpenAIBatchTrigger.run() that yielded a second, spurious error event after every terminal event (benign — only the first event is consumed — but incorrect).

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Claude Code

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[potiuk]

Three real defects here, and the first is the one that matters most.

A batch cancelled while the task was deferred completed successfully with no results, because execute_complete only raised on status == "error". The non-deferrable path has raised for CANCELLED/CANCELLING since wait_for_batch was fixed, so the same operator disagreed with itself depending on whether deferrable was set. Silent success on a cancelled job is about the worst failure shape there is.

Moving from a deny-list (== "error" raises) to an allow-list (!= "success" raises) is the right correction, and it is what makes unknown statuses fail loudly rather than being read as success — the general form of the bug rather than just the reported instance.

The stray error yield sitting outside the if/elif chain was worth catching too. In practice the triggerer consumes the first event and closes the generator, so it was probably latent rather than live, but it was plainly wrong.

I checked the thing most likely to break under the new allow-list: execute_complete dereferences event["message"] for every non-success event. Every branch of this trigger — success, cancelled, both error paths, and the exception handler — sets message, so that is safe.

One small inconsistency, worth a follow-up rather than holding this: the validator checks status but not message, and message is exactly what the caller dereferences next. A custom or version-skewed trigger emitting {"status": "cancelled"} alone would KeyError — precisely the "crash opaquely" failure the validator exists to prevent. event.get("message", event) at the raise site would close it.

I have added a note to the provider changelog rather than letting this land silently. Dags whose batches get cancelled will now fail where they previously went green, and that is worth operators reading before they upgrade, even though the earlier green runs produced no output.

---

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