Skip to content

Added runtime validation for Agent name field #998

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

DanielHashmi
Copy link
Contributor

@DanielHashmi DanielHashmi commented Jul 3, 2025

Add __post_init__ validation to ensure Agent name is a string

The Agent class previously only used type hints for the name field without
runtime validation, allowing non-string values like integers to be passed.
This caused downstream errors during JSON serialization, tracing, and other
operations that expect the name to be a string.

Changes:

  • Add post_init method to Agent class with isinstance check
  • Raise TypeError with descriptive message for non-string names
  • Validation occurs at instantiation time to fail fast

Fixes issue where Agent(name=1) would succeed but cause errors later
in the execution pipeline.

…evelopers" appears twice in the classifiers list. Line Number 20 and Line Number 26 Fix: Removed the duplicate classifier entry
…he tracing module where one import uses an absolute path in line number 3 while all others use relative imports
@seratch
Copy link
Member

seratch commented Jul 8, 2025

Related to #996; if we add this, we may want to have validation logic for other arguments too @rm-openai any opinion?

@DanielHashmi
Copy link
Contributor Author

Thanks for the feedback! You're right that this could be part of a broader validation pattern. Looking at the Agent class, several other fields could benefit from similar runtime validation:

  • instructions: Should validate str, callable, or None
  • tools: Should validate list of Tool objects
  • handoffs: Should validate list of Agent/Handoff objects
  1. Should we implement validation incrementally or all at once?
  2. Prefer individual isinstance checks in __post_init__ or a structured validation framework?
  3. Any specific validation patterns you'd like as the SDK standard?

I'm happy if I can expand this PR to include other critical fields or use this as a foundation for incremental validation. What approach works best for the team?

@seratch
Copy link
Member

seratch commented Jul 10, 2025

Should we implement validation incrementally or all at once?

Agent class currently has 16 fields, so adding all of them may take some time. If you're fine with it, your contribution would be appreciated. Otherwise, we can later add validations to the rest of the fields after merging this PR only with name.

Prefer individual isinstance checks in post_init or a structured validation framework?

Simply writing all logic in __post_init__ should be fine for now. Perhaps, most code would be combination of if XXX is not None and if isinstance(V, T).

Any specific validation patterns you'd like as the SDK standard?

Checking if a value is not None and then check the type of the value would be enough. I don't think we should scan all the elements of an array and nested property values (i.e., no need to check internal values of ModelSettings, each element of handoffs etc.). We may want to do similar to other data classes, but in this PR, we can focus on the Agent class.

@seratch
Copy link
Member

seratch commented Jul 10, 2025

I just noticed @rm-openai started refactoring of the class - #1044 ; aligning with this change and/or working on this PR after the refactoring is done would be appreciated 🙏

@DanielHashmi
Copy link
Contributor Author

Ok! will work on this after refactoring 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request feature:core
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants