[Lee-W]

Why

Once a Human-in-the-loop task stops waiting, for example after its response_timeout
expires and it fails because no defaults were set, the hitlDetails PATCH used to keep
accepting answers. The answer was stored and the API returned 200, but nothing resumed the task. A user answering from a page that was still open saw a success message for a decision that never took effect.

The UI error toast made the refusal hard to understand as well: it only showed the HTTP
status text ("Conflict"), which says nothing about why the answer was not accepted.

Closes: #75531

What

• The hitlDetails PATCH returns 409 and records nothing when the task instance is not
  waiting (awaiting_input or deferred). The check runs under the existing task instance lock, after authorization and option validation, so it cannot interleave with a concurrent clear.
• The error toast shows the detail the backend returns, and falls back to the previous
  message when there is none.

Behaviour worth calling out for review:

• The gate looks at task state only, not at whether the timeout has passed. A request that arrives after the timeout but before the scheduler has processed it is still accepted, because the task is still waiting and the response will resume it. Comparing against the timeout in the API would duplicate the scheduler's decision and could refuse an answer that the scheduler would have honoured. A test pins this case.
• The shared createErrorToaster is not changed. It is used in roughly 20 places across the UI, and changing its behaviour would affect all of them. The detail handling lives in useUpdateHITLDetail, and 403 is still left to the MutationCache handler as before.

---

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

• Yes (please specify the tool below)

Generated-by: [Claude] following the guidelines

---

• 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.

[github-actions]

Backport failed to create: v3-4-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-4-test

You can attempt to backport this manually by running:

cherry_picker d1491b8 v3-4-test

This should apply the commit to the v3-4-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.