[ccoliu]

closes: #72386

Description

Currently, the Airflow 3 UI only allows operators to manually mark a Task Instance as Success or Failed, but does not expose the option to mark it as Skipped.

However, the backend API (PatchTaskInstanceBody.validate_new_state) already accepts TaskInstanceState.SKIPPED as a valid target state. Marking a task as SUCCESS vs SKIPPED has distinct semantics in execution history, audit logs, and downstream trigger rule evaluation (e.g., none_failed vs none_skipped).

This PR:

1. Splits allowedStates in src/components/MarkAs/utils.ts into:
   • allowedRunStates: ["success", "failed"] (maintaining the existing constraint that Dag Runs cannot be marked skipped)
   • allowedTaskStates: ["success", "failed", "skipped"] (enabling skipped for task instances and task groups)
2. Updates MarkTaskInstanceAsButton, MarkTaskGroupAsButton, and BulkMarkTaskInstancesAsButton to use allowedTaskStates.
3. Adds the missing tooltip translation for skipped in en/dags.json.

Screenshots

Before	After
Only Success / Failed in Mark As menu	Success / Failed / Skipped (pink badge) available

---

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

• Yes (Claude Opus 5)

Generated-by: Antigravity IDE following the guidelines

[ccoliu]

This PR has been open for a bit and all CI checks are now green (Static checks, and Chromium/Firefox/WebKit UI e2e tests). It's a small, self-contained UI addition — exposing the existing "skipped" state (already supported by the backend API) as a "Mark as Skipped" option for Task Instances, matching the existing "Mark as Success/Failed" pattern.

Would appreciate a review when anyone has a moment! cc @bbovenzi @pierrejeambrun (saw you both active on related MarkAs/multi-team UI work recently)

[bbovenzi]

Sorry, I think this feature request needed more of a discussion before a code review. I am not sure if Mark as skipped is something we want to allow.

[ccoliu]

Thanks for taking a look, and no problem — agreed it makes sense to settle the behavior first. I'll convert this to a draft and follow the discussion on #72386.

For context, the public API's PATCH task instance endpoint already accepts skipped as new_state (see PatchTaskInstanceBody.validate_new_state), so this PR only exposes that existing capability in the UI. If the consensus is to restrict it — e.g. only for task instances that haven't started yet — I'm happy to adjust the PR accordingly, or close it if it's not something we want.

[pierrejeambrun]

Following the discussion on the linked issue do you mind updating the doc as well to highlight the common pitfall / nuances.

Also we might want to add an "info" text in the modal to highlight what 'mark as skip' is doing and also explain the gotchas there.

Also need gate on the tasks states we're setting to 'pending' (as mentioned in the discussion)

[ccoliu]

Thanks for the review and the discussion on #72386! Before updating the PR, I'd like to confirm two details:

1. Which states count as "pending"? I'm thinking: allow none, scheduled, up_for_reschedule (and possibly up_for_retry); disallow queued (could be picked up any moment), running, deferred, restarting, and all finished states. Does that match what you had in mind?
2. Where should the gate live? Since the dialog can also include upstream/downstream/past/future task instances, a check on the selected task alone in the UI isn't enough. Should we enforce it in the PATCH task instance endpoint when new_state is skipped (rejecting, or filtering out, non-pending TIs), or keep it UI-only for now?

I'd also suggest limiting this PR to single task instances (dropping skipped from the task group and bulk actions) to keep the scope manageable, unless you'd prefer otherwise.

Then I'll add the info text in the modal and a docs note on the cascade-skip behavior with the default all_success trigger rule.

[bbovenzi]

1. We already have a isStatePending() util in the UI project. But sounds like that its too expansive so I trust the states you picked.
2. Ideally we check this on the API but we can pre-empt the errors in the UI by only showing the skipped option depending on TI.state and that its a TI and not any group. Once we open the modal we can disable all the options that allow one to affect other TIs.

[ccoliu]

Thanks @bbovenzi and @pierrejeambrun! Updated following the discussion:

• Pending-only: "Skipped" is offered only for a single task instance with no state, scheduled, up_for_reschedule or up_for_retry (a narrower list than isStatePending(), which also includes running/queued/deferred states). It was removed from the task group, Dag run and bulk actions.
• No effect on other TIs: when marking as skipped, the past/future/upstream/downstream options are disabled and always sent as false, even if the user's default options include them.
• Info text in the modal explaining what skipping does and the trigger-rule pitfall.
• Docs: added a "Marking a Task Instance as skipped" section to core-concepts/tasks.rst.

I kept the gate in the UI for now; enforcing it in the PATCH endpoint could be a follow-up PR if you'd like.

Verified locally with a Dag mirroring the use case from #72386 (wait_for_file_b sensor in reschedule mode → ingestion_b → transformations, plus ingestion_a → transformations):

Sensor in up_for_reschedule	Already-succeeded task

Mark as skipped dialog:

After confirming, ingestion_b and transformations were skipped via the default all_success trigger rule, and the Dag run finished as success: