index-tasks silently disappear after one day
Categories
(Firefox Build System :: Task Configuration, defect)
Tracking
(Not tracked)
People
(Reporter: jlorenzo, Unassigned)
References
Details
After bug 1636849, I started to look at graphs that newly contained index-tasks. Everything looked good, all tasks were present. Today, I have a look at the most recent graph[1] (which is 2 days old) and I don't see any index-tasks. I was shocked. I assumed it was a regression so I started to look back at the graphs I knew were fine. Their index-tasks were gone too.
So I checked the logs of the decision task[1] and I could see the index-tasks were correctly generated[2]. They even exist if I enter the direct URL to them[3]. It's just they don't appear anymore in the task group view. I took a closer look and it turns out they expire after one day. This behavior has always been there[5] (bug 1333255). Changing it may break people's habit. That said, I wonder how many people have used the index-task feature and how many may fall into the same trap as I did.
Tom, do you think we should change this line[4] into:
'expires': task.task['expires'],
?
[1] https://firefox-ci-tc.services.mozilla.com/tasks/groups/KPhT6EeFQS2TZRWSa8j5LA - I was actually investigating why one of the task is red.
[2] https://firefox-ci-tc.services.mozilla.com/tasks/KPhT6EeFQS2TZRWSa8j5LA/runs/0/logs/https%3A%2F%2Ffirefox-ci-tc.services.mozilla.com%2Fapi%2Fqueue%2Fv1%2Ftask%2FKPhT6EeFQS2TZRWSa8j5LA%2Fruns%2F0%2Fartifacts%2Fpublic%2Flogs%2Flive.log#L131
[3] https://firefox-ci-tc.services.mozilla.com/tasks/Rhcycq1PSd69yGa09I-JMg
[4] https://hg.mozilla.org/ci/taskgraph/file/ddd3397bf197f4529f6a60c9138417211507e50e/src/taskgraph/morph.py#l66
[5] https://hg.mozilla.org/mozilla-central/rev/ddd3397bf197f4529f6a60c9138417211507e50e#l5.67
|
||
Comment 1•4 years ago
|
||
We definitely could. I'm curious what value keeping them provides (particularly in light of our work to minimize costs). I'll note that the tasks does not need to stick around, since it generates the indexes pointing at the parent task.
I don't feel strongly either way, but given that it hasn't been an issue for gecko in the 3 years since we implemented this, I'm curious how often these need to be looked at?
Did you need them for the debugging you were doing, or were you primed to see them, having just added support, and were surprised by the short expiry?
They even exist if I enter the direct URL to them.
I suspect that probably is a bug with the expiry process, and it probably should no longer be around. (Bug 1638921).
|
Reporter | |
Comment 2•4 years ago
|
||
I suspect that probably is a bug with the expiry process, and it probably should no longer be around. (Bug 1638921).
Makes sense! Thanks for pointing the bug out!
Did you need them for the debugging you were doing, or were you primed to see them, having just added support, and were surprised by the short expiry?
I'd say the latter. I was expecting to see the same graph as I saw when it got generated. I was confused to see smaller just a few days later. I guess I could see it because in the graphs above, half of the tasks were index ones. So it was easy for me to notice while in gecko, it's diluted in thousands of tasks.
I agree the cost argument is a strong point, in addition to the 3-year-behavior. I guess I can close this bug for now and we can reopen it if someone gets surprised the same way I did. I'll update this bug if I hear anything.
|
||
Comment 3•4 years ago
|
||
I've seen this with l10n tasks in release graphs too, it was a bit confusing at first that len(graph) sanity checks were getting different results but didn't cause me real issues.
Description
•