feat(mistralai): support stop sequences#38047
Merged
Merged
Conversation
`ChatMistralAI` now treats `stop` as a first-class constructor parameter instead of letting LangChain move it into `model_kwargs` with a warning. The related tests also avoid leaking `MISTRAL_BASE_URL` across test cases and explicitly assert the intentional unknown-kwarg warning path. Prepared with AI-agent assistance. ## Changes - Added `stop` to `ChatMistralAI` initialization so LangChain standard chat-model params no longer produce `model_kwargs` warnings. - Updated `_get_ls_params` and `_create_message_dicts` to read constructor-level `self.stop` while preserving the existing behavior that removes unsupported `stop` values before Mistral API requests. - Captured the intentional `foo` extra-kwarg warning in `test_extra_kwargs` with `pytest.warns`, so the test documents the expected warning instead of emitting noise. - Switched the Mistral base URL environment test to `monkeypatch.setenv`, preventing `MISTRAL_BASE_URL=boo` from leaking into later serialization tests. - Updated the standard serialization snapshot so `stop` appears as an explicit constructor kwarg and the default endpoint is no longer polluted by leaked environment state.
stop as chat parameterstop sequences
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ChatMistralAInow supportsstopsequences.Previously, a
stopvalue passed to the model was silently discarded: the code carried a stale "not yet supported" note, dropped the parameter before the request, and logged a warning. Mistral's chat completions API does acceptstop(a string or list of strings, up to 4 sequences), so anyone settingstopand expecting generation to halt was getting no effect.Now
stopis a first-class parameter. It can be set on the constructor (ChatMistralAI(stop=[...])) or per call (model.invoke(prompt, stop=[...])) and is forwarded to the API. A per-call value overrides the instance default, and an empty list is treated as "no stop sequences" — omitted from the request rather than sent as an empty array (which the API rejects).Verified against the live Mistral API: with
stop=["5"], "Count from 1 to 10" returns1 2 3 4instead of the full sequence. The 422extra_forbiddenresponse the API returns for genuinely unknown fields confirmsstopis a real schema field, not silently ignored.This PR also folds in some test hygiene: the base-URL env test uses
monkeypatch.setenvsoMISTRAL_BASE_URL=boono longer leaks into later serialization tests, andtest_extra_kwargsasserts the intentional unknown-kwarg warning withpytest.warns.Review notes
stopnow reaches the API instead of being dropped. This changes request payloads for anyone previously passingstop. It is the intended fix, but flagging it explicitly.test_stop_sequence(integration) exercises the end-to-end behavior; unit tests cover parameter wiring, per-call-vs-instance precedence, and the empty-list case.