-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update retcodes to handle new cases #1771
Changes from 9 commits
bca9c50
8ebb073
dc1c7c9
fa906a0
c0d4b9e
19e934a
e08185e
54ca4a3
dde2a24
df526af
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -58,6 +58,13 @@ def _partition_tasks(worker): | |
return set_tasks | ||
|
||
|
||
def _root_task(worker): | ||
""" | ||
Return the first task scheduled by the worker, corresponding to the root task | ||
""" | ||
return worker._add_task_history[0][0] | ||
|
||
|
||
def _populate_unknown_statuses(set_tasks): | ||
""" | ||
Add the "upstream_*" and "unknown_reason" statuses my mutating set_tasks. | ||
|
@@ -270,15 +277,15 @@ def _get_comments(group_tasks): | |
("already_done", 'present dependencies were encountered'), | ||
("completed", 'ran successfully'), | ||
("failed", 'failed'), | ||
("scheduling_error", 'failed running complete() or requires()'), | ||
("scheduling_error", 'failed scheduling'), | ||
("still_pending", 'were left pending, among these'), | ||
("still_pending_ext", 'were missing external dependencies'), | ||
("run_by_other_worker", 'were being run by another worker'), | ||
("upstream_failure", 'had failed dependencies'), | ||
("upstream_missing_dependency", 'had missing external dependencies'), | ||
("upstream_run_by_other_worker", 'had dependencies that were being run by other worker'), | ||
("upstream_scheduling_error", 'had dependencies whose complete() or requires() failed'), | ||
("unknown_reason", 'were left pending because of unknown reason'), | ||
("upstream_scheduling_error", 'had dependencies whose scheduling failed'), | ||
("unknown_reason", 'did not run successfully because of unknown reason'), | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When the task fails There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Mhm, it stems from this part of discussion. Thinking about the cases of disabling and resources missing, it's still true that the instance remained "pending". (In the common sense common denominator of those more detailed statuses. If we invested more in status propagation we would come up with summaries like "pending because missing resources" etc.) I'm saying that in my view the higher level conceptual task's flow hasn't changed much and doesn't risk changing much. It's first pending, then becomes running (the moment when There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Alternatively, a valid wording would be "did not run", because that's equivalent to the common sense "left pending" (didn't enter There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think you're spot on Uldis. Let's say "did not run" or "wasnt permitted to run" (to remind users that who decides this is actually the central scheduler). |
||
)) | ||
|
||
|
||
|
@@ -374,10 +381,13 @@ def _summary_format(set_tasks, worker): | |
smiley = ":(" | ||
reason = "there were failed tasks" | ||
if set_tasks["scheduling_error"]: | ||
reason += " and tasks whose complete() or requires() failed" | ||
reason += " and tasks whose scheduling failed" | ||
elif set_tasks["scheduling_error"]: | ||
smiley = ":(" | ||
reason = "there were tasks whose complete() or requires() failed" | ||
reason = "there were tasks whose scheduling failed" | ||
elif set_tasks["unknown_reason"]: | ||
smiley = ":|" | ||
reason = "there were tasks that did not run successfully because of unknown reason" | ||
elif set_tasks["still_pending_ext"]: | ||
smiley = ":|" | ||
reason = "there were missing external dependencies" | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missed the comment suggesting "38 or 0". The comment doesn't describe the benefit. I would -1 this convoluted wording as overcomplication.
0 is already the default value. The existing users who perform retcode configuration won't be taken by surprise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, lets not complicate things. The benefit I was looking for was to say that this return code is "no problem, don't worry".
What about using a number but a much lower number? I noticed we already say they are in increasing order of severity (I had forgotten this). Maybe use the number
15
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, I was going to suggest 25. (As said, for a human operator, "not run for unknown reason" IMO evaluates worse than "not run for <insert known reason, like missing data>".)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. I imagined
10 < x < 30
. So 25 sounds good because of the reason you said.