Skip to content

fix: parse pydantic output before first guardrail invocation#4624

Open
Anandesh-Sharma wants to merge 1 commit intocrewAIInc:mainfrom
Anandesh-Sharma:fix/4369-guardrail-pydantic-output
Open

fix: parse pydantic output before first guardrail invocation#4624
Anandesh-Sharma wants to merge 1 commit intocrewAIInc:mainfrom
Anandesh-Sharma:fix/4369-guardrail-pydantic-output

Conversation

@Anandesh-Sharma
Copy link

Summary

  • Fixes TaskOutput.pydantic being None on the first guardrail call but populated on retries
  • _export_output() was intentionally skipped when guardrails were present, causing inconsistent behavior
  • Now _export_output() is always called, so guardrail functions receive consistent TaskOutput with pydantic data on every invocation
  • Fixed in both sync (_execute_core) and async (_aexecute_core) paths

Fixes #4369

Test plan

  • Create a Task with output_pydantic and a guardrail function
  • Verify task_output.pydantic is populated on the first guardrail invocation
  • Verify retry attempts still have task_output.pydantic populated
  • Verify tasks without guardrails still work correctly

🤖 Generated with Claude Code

When guardrails are configured, _export_output() was intentionally
skipped on the first attempt, setting pydantic_output to None. This
meant task_output.pydantic was None on the first guardrail call but
correctly populated on retries, creating inconsistent behavior.

Now _export_output() is always called regardless of guardrails, so
guardrail functions receive consistent TaskOutput with pydantic data
on every invocation. Fixed in both sync and async execution paths.

Fixes crewAIInc#4369

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] TaskOutput.pydantic is None on first guardrail attempt but parsed on retries

1 participant