Improve scope error handling#873
Merged
Merged
Conversation
ahal
force-pushed
the
ahal/push-rkmlwsluyvzr
branch
13 times, most recently
from
December 12, 2025 17:38
2946aee to
a297b24
Compare
ahal
marked this pull request as ready for review
December 12, 2025 17:38
ahal
marked this pull request as draft
December 12, 2025 18:43
ahal
force-pushed
the
ahal/push-rkmlwsluyvzr
branch
2 times, most recently
from
December 12, 2025 21:40
9edbb74 to
b1605da
Compare
ahal
marked this pull request as ready for review
December 12, 2025 21:46
This allows us to get more coverage out of these tests.
This prints the label of the task we failed to create for convenience, as well as defers failing the Decision task until after we've attempted all tasks. This way we'll see all the scope errors at once rather than needing to fix them one at a time.
ahal
force-pushed
the
ahal/push-rkmlwsluyvzr
branch
from
December 15, 2025 14:19
b1605da to
eb3fee6
Compare
bhearsum
added a commit
to bhearsum/taskgraph
that referenced
this pull request
Jun 30, 2026
I noticed this as an intermittent test failure in CI, which looks like a minor regression from taskcluster#873: ``` [task 2026-06-29T11:51:43.891+00:00] ______________ TestCreate.test_create_tasks_fails_if_create_fails ______________ [task 2026-06-29T11:51:43.891+00:00] [task 2026-06-29T11:51:43.891+00:00] self = <test.test_create.TestCreate testMethod=test_create_tasks_fails_if_create_fails> [task 2026-06-29T11:51:43.891+00:00] [task 2026-06-29T11:51:43.891+00:00] @responses.activate [task 2026-06-29T11:51:43.891+00:00] @mock.patch.dict( [task 2026-06-29T11:51:43.891+00:00] "os.environ", [task 2026-06-29T11:51:43.891+00:00] {"TASKCLUSTER_ROOT_URL": "https://tc.example.com"}, [task 2026-06-29T11:51:43.891+00:00] clear=True, [task 2026-06-29T11:51:43.891+00:00] ) [task 2026-06-29T11:51:43.891+00:00] def test_create_tasks_fails_if_create_fails(self): [task 2026-06-29T11:51:43.891+00:00] "create_tasks fails if a single create_task call fails" [task 2026-06-29T11:51:43.891+00:00] mock_taskcluster_api(error_status=403, error_message="oh no!") [task 2026-06-29T11:51:43.891+00:00] [task 2026-06-29T11:51:43.891+00:00] tasks = { [task 2026-06-29T11:51:43.891+00:00] "tid-a": Task( [task 2026-06-29T11:51:43.891+00:00] kind="test", label="a", attributes={}, task={"payload": "hello world"} [task 2026-06-29T11:51:43.891+00:00] ), [task 2026-06-29T11:51:43.891+00:00] } [task 2026-06-29T11:51:43.891+00:00] label_to_taskid = {"a": "tid-a"} [task 2026-06-29T11:51:43.891+00:00] graph = Graph(nodes={"tid-a"}, edges=set()) [task 2026-06-29T11:51:43.891+00:00] taskgraph = TaskGraph(tasks, graph) [task 2026-06-29T11:51:43.891+00:00] [task 2026-06-29T11:51:43.891+00:00] > with self.assertRaises(CreateTasksException): [task 2026-06-29T11:51:43.891+00:00] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [task 2026-06-29T11:51:43.891+00:00] E AssertionError: CreateTasksException not raised ``` It's probably impossible to hit in any non-trivial taskgraph in production, but it's certainly something that *could* happen, particularly in smaller/shallower graphs. The fix is moving the error checking out to the main flow of control, and doing it synchronously. This leaves `handle_exception` doing nothing except populated `skipped`, so I moved it into `schedule_tasks` and renamed it to make that a bit more obvious.
bhearsum
added a commit
that referenced
this pull request
Jun 30, 2026
I noticed this as an intermittent test failure in CI, which looks like a minor regression from #873: ``` [task 2026-06-29T11:51:43.891+00:00] ______________ TestCreate.test_create_tasks_fails_if_create_fails ______________ [task 2026-06-29T11:51:43.891+00:00] [task 2026-06-29T11:51:43.891+00:00] self = <test.test_create.TestCreate testMethod=test_create_tasks_fails_if_create_fails> [task 2026-06-29T11:51:43.891+00:00] [task 2026-06-29T11:51:43.891+00:00] @responses.activate [task 2026-06-29T11:51:43.891+00:00] @mock.patch.dict( [task 2026-06-29T11:51:43.891+00:00] "os.environ", [task 2026-06-29T11:51:43.891+00:00] {"TASKCLUSTER_ROOT_URL": "https://tc.example.com"}, [task 2026-06-29T11:51:43.891+00:00] clear=True, [task 2026-06-29T11:51:43.891+00:00] ) [task 2026-06-29T11:51:43.891+00:00] def test_create_tasks_fails_if_create_fails(self): [task 2026-06-29T11:51:43.891+00:00] "create_tasks fails if a single create_task call fails" [task 2026-06-29T11:51:43.891+00:00] mock_taskcluster_api(error_status=403, error_message="oh no!") [task 2026-06-29T11:51:43.891+00:00] [task 2026-06-29T11:51:43.891+00:00] tasks = { [task 2026-06-29T11:51:43.891+00:00] "tid-a": Task( [task 2026-06-29T11:51:43.891+00:00] kind="test", label="a", attributes={}, task={"payload": "hello world"} [task 2026-06-29T11:51:43.891+00:00] ), [task 2026-06-29T11:51:43.891+00:00] } [task 2026-06-29T11:51:43.891+00:00] label_to_taskid = {"a": "tid-a"} [task 2026-06-29T11:51:43.891+00:00] graph = Graph(nodes={"tid-a"}, edges=set()) [task 2026-06-29T11:51:43.891+00:00] taskgraph = TaskGraph(tasks, graph) [task 2026-06-29T11:51:43.891+00:00] [task 2026-06-29T11:51:43.891+00:00] > with self.assertRaises(CreateTasksException): [task 2026-06-29T11:51:43.891+00:00] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [task 2026-06-29T11:51:43.891+00:00] E AssertionError: CreateTasksException not raised ``` It's probably impossible to hit in any non-trivial taskgraph in production, but it's certainly something that *could* happen, particularly in smaller/shallower graphs. The fix is moving the error checking out to the main flow of control, and doing it synchronously. This leaves `handle_exception` doing nothing except populated `skipped`, so I moved it into `schedule_tasks` and renamed it to make that a bit more obvious.
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.
No description provided.