Simplify "invalid TI state" message #19029
Merged
Conversation
This file contains 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
uranusjr
approved these changes
Oct 18, 2021
exactly :)
I agree it could probably use a refactor but it doesn't seem super high priority. |
Currently in the web UI on task instance details page, if a task is in the "up for retry" state we will see this message: "Task is in the up_for_retry state which is not a valid state for execution. The task must be cleared in order to be run." This might suggest to the user "you need to clear this in order for this task to run". But this is not true. But it is not simple to make it clearer, because this function is used for a lot of different scenarios. For example, checking for "schedulable" tasks, and "queueable" tasks. So not only would we need to keep track of which states actually require user intervention, but the desired action (e.g. queue vs schedule vs run). So I think the best course of action is to simplify this to say only what is always true, and that is just the state.
dstandish
force-pushed
the
simplify-invalid-ti-state-dep-message
branch
from
c981628
to
d7b9e42
Compare
kaxil
approved these changes
Nov 2, 2021
github-actions
bot
added
the
full tests needed
|
The PR most likely needs to run full matrix of tests because it modifies parts of the core of Airflow. However, committers might decide to merge it quickly and take the risk. If they don't merge it quickly - please rebase it to the latest main at your convenience, or amend the last commit of the PR, and push it with --force-with-lease. |
ashb
approved these changes
Nov 4, 2021
|
Nice commit message too ❤️ |
jedcunningham
pushed a commit
that referenced
this pull request
Dec 7, 2021
Currently in the web UI on task instance details page, if a task is in the "up for retry" state we will see this message: "Task is in the up_for_retry state which is not a valid state for execution. The task must be cleared in order to be run." This might suggest to the user "you need to clear this in order for this task to run". But this is not true. But it is not simple to make it clearer, because this function is used for a lot of different scenarios. For example, checking for "schedulable" tasks, and "queueable" tasks. So not only would we need to keep track of which states actually require user intervention, but the desired action (e.g. queue vs schedule vs run). So I think the best course of action is to simplify this to say only what is always true, and that is just the state. (cherry picked from commit 72679be)
38 tasks
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.
Currently in the web UI on task instance details page, if a task is in the "up for retry" state
we will see this message:
First of all, there's nothing really "invalid" about this state -- it's expected that sometimes tasks will fail, then be in up-for-retry state before being retried. So, it is a valid state, and it will get picked up after the retry interval.
But the language "The task must be cleared in order to be run" suggests to the user "you need to clear this in order for this task to run". But this is not true.
Unfortunately it is not simple to make it clearer, because this function is used for a lot of different scenarios. For example, checking for "schedulable" tasks, and "queueable" tasks. So not only would we need to keep track of which states actually require user intervention, but the desired action (e.g. queue vs schedule vs run).
So I think the best course of action is to amend this to say less, i.e. to say only what is always true, which is simply the state.