Fix task.copy() to preserve NOT_SPECIFIED context (fixes #3691) #3692
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.
Fix task.copy() to preserve NOT_SPECIFIED context (fixes #3691)
Summary
This PR fixes a bug where
Task.copy()
incorrectly convertedNOT_SPECIFIED
context values toNone
during task copying. This affectedkickoff_for_each
andkickoff_for_each_async
methods when copying tasks with the defaultNOT_SPECIFIED
context.Root Cause: The original logic only checked
if isinstance(self.context, list)
, causingNOT_SPECIFIED
(which is falsy) to fall through to theelse None
case.Fix: Added an explicit check for
NOT_SPECIFIED
before the list/None handling to preserve the sentinel value.Changes:
if self.context is NOT_SPECIFIED:
check inTask.copy()
methodcopy
→shallow_copy
for clarityReview & Testing Checklist for Human
pytest tests/test_task.py::test_task_copy_preserves_not_specified_context -vv
to confirm the test fails without the fixkickoff_for_each([input1, input2])
works correctly without converting NOT_SPECIFIED to NoneNotes
Link to Devin run: https://app.devin.ai/sessions/136dd806c654415fa702281360a2e462
Requested by: João ([email protected])
Environment Note: Local testing was blocked by corrupted uv.lock file, so CI verification is essential. The fix logic matches the pattern from PR #3690 which had the same solution.