Skip to content

only include tool_calls or tool_call_id in requests #3170

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

Closed

Conversation

burtenshaw
Copy link

@burtenshaw burtenshaw commented Jun 19, 2025

This PRs validate the chat completion requests to tools via inference providers use the correct schema.

@HuggingFaceDocBuilderDev

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@burtenshaw burtenshaw marked this pull request as ready for review June 19, 2025 17:52
@burtenshaw burtenshaw requested a review from hanouticelina June 19, 2025 17:52
@burtenshaw burtenshaw changed the title remove tool_calls from requests for groq only include tool_calls or tool_call_id in requests Jun 23, 2025
@burtenshaw
Copy link
Author

Hey @hanouticelina Do you want to merge this PR?

tool_call_id: Optional[str] = None
refusal: Optional[str] = None

def __post_init__(self) -> None:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this mean it's broken for all providers currently? 😅

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's broken for all providers, my intuition is that groq seems to be a bit more strict on this

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. I tested on other providers and it seems that groq is the only one to enforce.

@hanouticelina
Copy link
Contributor

@burtenshaw hey Ben, sorry for the late reply! let's wait for @Wauplin's feedback tomorrow and then we will merge and do a patch release as soon as possible.

@Wauplin
Copy link
Contributor

Wauplin commented Jun 24, 2025

I'm suggesting a different solution in #3178. If you feel strongly about it, we can go with this one though. I just wanted to check if we could have a broader solution to avoid BadRequest errors because of some None values

@burtenshaw
Copy link
Author

I'm suggesting a different solution in #3178. If you feel strongly about it, we can go with this one though. I just wanted to check if we could have a broader solution to avoid BadRequest errors because of some None values

LGTM

@hanouticelina
Copy link
Contributor

closing this as the issue is now solved in #3178

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.

5 participants