Repository navigation
Refuse Human-in-the-loop responses once the task stopped waiting (#75645) - #75706
Merged
vatsrahul1001 merged 1 commit intoOct 27, 2026
Merged
Conversation
…che#75645) * Refuse Human-in-the-loop responses once the task stopped waiting The hitlDetails PATCH recorded a response whenever none existed yet and only resumed the task if it was still awaiting input or deferred. After a response_timeout without defaults, an answer was stored and returned 200 although nothing resumed, so the UI reported success for a decision that never took effect. Return 409 before writing when the task instance is in any other state. The check runs under the existing task instance lock, after the authorization and option validation, and looks at the state only: a request whose timeout has passed but that the scheduler has not yet processed is still accepted. * Show why the backend refused a Human-in-the-loop response The error toast showed only the HTTP status text ("Conflict") when a response was refused. Show the detail the backend returns, such as that the task is no longer waiting for a response, and fall back to the previous message when there is none. * Cover the refusal toast for validation, mapping, missing and forbidden details (cherry picked from commit d1491b8)
Lee-W
requested review from
bbovenzi,
bugraoz93,
choo121600,
ephraimbuddy,
guan404ming,
henry3260,
jason810496,
pierrejeambrun,
rawwar,
ryanahamilton,
shubhamraj-git and
vatsrahul1001
as code owners
October 27, 2026 03:54
Contributor
|
Hi maintainer, this PR was merged without a milestone set.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The hitlDetails PATCH recorded a response whenever none existed yet and only resumed the task if it was still awaiting input or deferred. After a response_timeout without defaults, an answer was stored and returned 200 although nothing resumed, so the UI reported success for a decision that never took effect.
Return 409 before writing when the task instance is in any other state. The check runs under the existing task instance lock, after the authorization and option validation, and looks at the state only: a request whose timeout has passed but that the scheduler has not yet processed is still accepted.
The error toast showed only the HTTP status text ("Conflict") when a response was refused. Show the detail the backend returns, such as that the task is no longer waiting for a response, and fall back to the previous message when there is none.
(cherry picked from commit d1491b8)
Was generative AI tooling used to co-author this PR?
{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.