Issue Station
Sign In
Tools hereToolbox

crewai - ✅(Solved) Fix Enforce deterministic ordering for equal-priority crew tasks [3 pull requests, 2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
crewAIInc/crewAI#4664•Fetched 2026-04-08 00:40:47
View on GitHub
Comments
2
Participants
2
Timeline
11
Reactions
0
Author
davidahmanndavidahmann
Participants
davidahmanndavidahmanngithub-actions[bot]github-actions[bot]
Timeline (top)
referenced ×4cross-referenced ×3commented ×2closed ×1

Fix Action

Fix / Workaround

Evidence packet

  • Commit under test: 1ac58015 (origin/main)
  • Runtime environment: macOS arm64, Python 3.14.0
  • Minimal repro:
    1. Build crew with multiple same-priority tasks.
    2. Execute repeatedly under same seed/config.
    3. Observe task dispatch order.
  • Expected: stable deterministic order.
  • Actual: order contract is not explicitly guaranteed by tests.

PR fix notes

PR #4665: fix: enforce deterministic ordering for equal-priority crew tasks

Description (problem / solution / changelog)

Summary

Addresses #4664 by making the task insertion-order execution contract explicit and adding regression tests.

Changes:

  • Added _execution_index: int | None PrivateAttr to Task — stamped at Crew construction time with each task's position in the list.
  • Added stamp_execution_order model validator on Crew that assigns the index to every task on initialization.
  • Updated docstrings on _execute_tasks and _aexecute_tasks to document the deterministic ordering contract.
  • Added 8 regression tests covering: index stamping, sync dispatch order, async dispatch order, identical-description tasks, single-task edge case, copy preservation, and output ordering.

Design note

The existing execution loops (_execute_tasks, _aexecute_tasks) already iterate in list order via enumerate(tasks), so Python list semantics were already deterministic. This PR formalizes that as an explicit, documented contract with the _execution_index metadata and comprehensive tests — it does not add a runtime sorted() call. A defensive sorted() was considered and reverted because it introduced risks with shared Task objects across multiple Crew instances (see commit history).

Review & Testing Checklist for Human

  • _execution_index is metadata only — no runtime sort: The execution loops still iterate via enumerate(tasks) (list order). The _execution_index field is stamped for observability and test assertions but is not read by any production code path. Confirm this level of enforcement is sufficient for the issue's requirements.
  • Shared task objects across crews: stamp_execution_order mutates _execution_index directly on Task objects. If the same Task instance is passed to two different Crew constructors, the second crew's stamping overwrites the first's indices. This only affects the metadata field and not actual execution order (which is driven by list position), but verify this edge case is acceptable.
  • Validator ordering: stamp_execution_order runs before validate_tasks in class definition order. Confirm no other validators depend on _execution_index being set or unset.

Suggested test plan:

  1. Review the 8 new tests in lib/crewai/tests/crew/test_deterministic_task_ordering.py — they cover stamping, sync/async dispatch, identical descriptions, single-task, copy, and output ordering.
  2. Construct a Crew with several tasks and verify task._execution_index matches position.
  3. Optionally, share Task instances across two Crew objects in different orders and verify each crew still executes in its own list order.

Notes

Changed files

  • lib/crewai/src/crewai/crew.py (modified, +30/-8)
  • lib/crewai/src/crewai/task.py (modified, +1/-0)
  • lib/crewai/tests/crew/test_deterministic_task_ordering.py (added, +252/-0)

PR #4666: Add regression test for deterministic equal-priority task order

Description (problem / solution / changelog)

Problem

Equal-priority task execution ordering was not explicitly regression-tested, risking non-deterministic sequencing across runs.

Why now

Deterministic crew/task lifecycle behavior is required for stable orchestration and replayability.

What changed

  • Added test_equal_priority_tasks_preserve_declared_order in lib/crewai/tests/test_crew.py.
  • Uses equal task priorities and captures execution order through a patched Agent.execute_task.
  • Asserts both execution order and tasks_output order match declaration order.

Validation

  • uv run pytest -q tests/test_crew.py -k equal_priority_tasks_preserve_declared_order

Refs #4664

<!-- CURSOR_SUMMARY -->

[!NOTE] Low Risk Low risk: test-only change that adds coverage for deterministic task ordering without modifying runtime code paths.

Overview Adds a new regression test ensuring sequential crews execute tasks in the exact order they are declared, even when task descriptions could sort differently (e.g., Task 2, Task 10, Task 1).

The test patches Agent.execute_task to capture the observed execution sequence and asserts both execution order and CrewOutput.tasks_output ordering match the declared task list.

<sup>Written by Cursor Bugbot for commit 2caac657894382f03b7f2acf6007cdf0c8ae326f. This will update automatically on new commits. Configure here.</sup>

<!-- /CURSOR_SUMMARY -->

Changed files

  • lib/crewai/tests/test_crew.py (modified, +39/-0)

PR #4734: Enforce deterministic task ordering for equal priorities (#4664)

Description (problem / solution / changelog)

Summary

This PR implements issue #4664.

  • Scope: Enforce deterministic ordering for equal-priority crew tasks
  • Source branch: yuweuii:codex/issue-4664
  • Commit: c714c5af

Linked Issue

Closes #4664

<!-- CURSOR_SUMMARY -->

[!NOTE] Medium Risk Changes core task execution ordering by sorting Crew.tasks during model validation, which could alter runtime behavior for users relying on the previous ordering semantics. The change is guarded by a stable tie-breaker and has focused test coverage, but it affects workflow sequencing.

Overview Deterministic task sequencing: Crew now sorts tasks by descending Task.priority during validation, using insertion order as a stable tie-breaker so equal-priority tasks run deterministically.

New task attribute: Adds priority (default 0) to Task and to YAML-backed TaskConfig, plus tests asserting stable execution order for equal priorities and correct ordering when priorities differ.

<sup>Written by Cursor Bugbot for commit bfa6fa712603f5e994b14b784681276046fba185. This will update automatically on new commits. Configure here.</sup>

<!-- /CURSOR_SUMMARY -->

Changed files

  • lib/crewai/src/crewai/crew.py (modified, +13/-0)
  • lib/crewai/src/crewai/project/crew_base.py (modified, +1/-0)
  • lib/crewai/src/crewai/task.py (modified, +5/-0)
  • lib/crewai/tests/test_crew.py (modified, +108/-0)
RAW_BUFFERClick to expand / collapse

Problem

Equal-priority crew tasks can execute in non-deterministic order, which makes behavior and debugging inconsistent across runs.

Why now

Reproducibility is essential for multi-agent workflows and regression triage.

Current behavior is insufficient

Execution order for same-priority tasks lacks a locked deterministic tie-break contract.

Expected behavior

Define and enforce deterministic task ordering for equal-priority tasks (for example stable insertion order or documented tie-break key).

Acceptance / Validation

  • Add/adjust execution ordering logic where needed.
  • Add regression tests that run same-priority fixtures multiple times and assert identical order.
  • Keep behavior scoped to equal-priority tie-break semantics.

Evidence packet

  • Commit under test: 1ac58015 (origin/main)
  • Runtime environment: macOS arm64, Python 3.14.0
  • Minimal repro:
    1. Build crew with multiple same-priority tasks.
    2. Execute repeatedly under same seed/config.
    3. Observe task dispatch order.
  • Expected: stable deterministic order.
  • Actual: order contract is not explicitly guaranteed by tests.

Likely codepaths

lib/crewai/src/crewai/crews, lib/crewai/src/crewai/tasks.

extent analysis

Fix Plan

To enforce deterministic task ordering for equal-priority tasks, we will implement a stable insertion order tie-break contract.

Steps:

  • Modify the Task class to include a unique insertion_order attribute.
  • Update the Crew class to maintain a list of tasks in insertion order.
  • Implement a custom sorting function that breaks ties based on insertion_order.

Example Code:

from dataclasses import dataclass
from typing import List

@dataclass
class Task:
    priority: int
    insertion_order: int

class Crew:
    def __init__(self):
        self.tasks = []

    def add_task(self, task: Task):
        self.tasks.append(task)

    def sort_tasks(self):
        self.tasks.sort(key=lambda x: (x.priority, x.insertion_order))

# Example usage:
crew = Crew()
task1 = Task(priority=1, insertion_order=1)
task2 = Task(priority=1, insertion_order=2)
crew.add_task(task1)
crew.add_task(task2)
crew.sort_tasks()
print([task.insertion_order for task in crew.tasks])  # Output: [1, 2]

Verification

To verify the fix, add regression tests that run same-priority fixtures multiple times and assert identical order.

Extra Tips

  • Use a consistent sorting algorithm to ensure deterministic results.
  • Consider adding a tie_break_key attribute to the Task class for more flexible tie-breaking logic.
  • Update documentation to reflect the new deterministic task ordering behavior.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Define and enforce deterministic task ordering for equal-priority tasks (for example stable insertion order or documented tie-break key).

#api#ssr#installation#tensor shape#autograd error#batch processing#GPU compatibility#latency issue#model loading#dependency error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING