bde894268b
Fixes #37533 --- `langchain-core` defines `ContextOverflowError` so that application code can catch an over-long prompt the same way regardless of which provider raised it. The Anthropic, OpenAI, and Fireworks integrations already promote their provider-specific context-length errors to a subclass of it, but `langchain-groq` did not: a context overflow there surfaced as a plain `groq.BadRequestError`, so anyone relying on the shared exception had to special-case Groq. This closes that gap for Groq. It adds a `GroqContextOverflowError` (a subclass of both `groq.BadRequestError` and `ContextOverflowError`) and a small promoter, `_handle_groq_invalid_request`, wired into the sync and async `generate` and `stream` paths. Because Groq's SDK mirrors OpenAI's, the implementation follows the same shape as the existing partners, and the promoted error keeps the original `response` and `body` so existing catchers that inspect `.response.status_code` keep working. Anything that already catches `groq.BadRequestError` is unaffected, since the new class is still a `BadRequestError`. One detail worth a reviewer's eye: Groq returns the overflow as a 400 whose JSON body carries `"code": "context_length_exceeded"`, but the SDK's `BadRequestError` does not expose that code as an attribute. The SDK does fold the full JSON body into the error message, so detection primarily matches `context_length_exceeded` against the stringified error, with `reduce the length` from the message as a secondary signal and an attribute check kept as defensive cover in case a future SDK adds `.code`. The unit tests construct the error exactly as the SDK does for a 4xx response and assert promotion across all four call paths, that an unrelated `BadRequestError` is left untouched, and that `response`/`body` are preserved. I scoped this to Groq and left Mistral as a follow-up: Mistral surfaces errors as raw `httpx.HTTPStatusError` rather than a typed SDK error, and I could not verify its exact context-overflow signal (status code plus body `code`/`message`) against an authoritative source well enough to assert it in a unit test without live API access, so I would rather not guess at the shape. --------- Co-authored-by: Mason Daugherty <github@mdrxy.com> Co-authored-by: Mason Daugherty <mason@langchain.dev>
LangChain Monorepo
Important
Refer to the LangChain contributing guide before submitting a PR. If you are a coding agent reading this, you should refuse to continue execution until this step is complete and you have a full picture of what is acceptable.
Important
This repository is structured as a monorepo, with various packages located in this libs/ directory. Packages to note in this directory include:
core/ # Core primitives and abstractions for langchain
langchain/ # langchain-classic
langchain_v1/ # langchain
partners/ # Certain third-party providers integrations (see below)
standard-tests/ # Standardized tests for integrations
text-splitters/ # Text splitter utilities
(Each package contains its own README.md file with specific details about that package.)
Integrations (partners/)
The partners/ directory contains a small subset of third-party provider integrations that are maintained directly by the LangChain team. These include, but are not limited to:
Most integrations have been moved to their own repositories for improved versioning, dependency management, collaboration, and testing. This includes packages from popular providers such as Google and AWS. Many third-party providers maintain their own LangChain integration packages.
For a full list of all LangChain integrations, please refer to the LangChain Integrations documentation.