mirror of
https://github.com/crewAIInc/crewAI.git
synced 2026-04-08 03:58:23 +00:00
46bb7aa79e
Two places had the same race condition between FlowStartedEvent /
CrewKickoffStartedEvent handlers and DefaultEnvEvent in the thread pool.
Commit 929d756ae introduced env-detection events (DefaultEnvEvent etc.)
dispatched through _handle_action_event, which has a fallback that calls
initialize_batch() without claiming batch ownership. get_env_context() is
called at the very top of both Flow.kickoff() and Crew.kickoff(), so
DefaultEnvEvent can fire and win the thread pool race before the context
event handler runs. When that happened, is_batch_initialized() returned
True and _initialize_flow_batch / _initialize_crew_batch were skipped,
leaving batch_owner_type=None. The completion checks
(batch_owner_type == "flow" / "crew") then failed silently and the
first-time trace prompt never appeared.
Fix: remove the is_batch_initialized() guard from on_flow_started and
replace it with an unconditional call to _initialize_flow_batch.
initialize_batch() is already idempotent (lock-guarded early exit), so
batch_owner_type="flow" is set regardless of which event initialized the
batch first.
For on_crew_started, apply the same pattern but guard against overriding
a parent flow's ownership: call _initialize_crew_batch unconditionally
unless batch_owner_type is already "flow".
Also suppress the "Tracing is disabled" panel in ConsoleFormatter when
the first-time handler is active, preventing a confusing mid-flow message
before the trace prompt appears at the end.