QVAC-24064 chore: release @qvac/cli 0.14.0 - #4545
Draft
opaninakuffo wants to merge 4 commits into
Draft
opaninakuffo wants to merge 4 commits into
opaninakuffo wants to merge 4 commits into
Conversation
Contributor
License compliance — cleanNo new dependency license findings in this PR. Warn-only (shadow) mode — this check does not block merges yet. Updated automatically by the canonical license compliance workflow. NOTICE presence (advisory)Missing NOTICE (advisory, does not block):
|
opaninakuffo
changed the title
simon-iribarren
previously approved these changes
Sep 18, 2026
opaninakuffo
changed the title
…4524) * QVAC-23460 feat[api]: accept tool_choice on the serve OpenAI routes The SDK takes generationParams.tool_choice as a bare string, but serve never read the field, so a client asking for a forced tool silently got an ordinary sampled turn. Chat and Responses now map it: the mode strings pass through, and the object form collapses to the tool name the SDK wants (chat nests it under `function`, Responses flattens it). A demanding choice with no matching tool is rejected as 400 invalid_tool_choice rather than reaching completion() and coming back a 500. toolError events are drained and logged with their codes. OpenAI has no response field for a tool call that failed to parse, and without the log line an empty `stop` response looks like the model just chose not to call one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * QVAC-23460 test: pin invalid_tool_choice on the wire The mapper was unit-tested but the 400 itself wasn't, so a route that stopped translating InvalidToolChoiceError would still have looked green. Loads the model with tools on, so these can only be the tool_choice check and never the load-flag gate tools-flag.test.ts covers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * QVAC-23460 test: cover the tool_choice success path over HTTP The e2e cases were all rejections, so nothing proved a valid tool_choice actually reaches the SDK -- only that bad input is turned away. Adds a completionOverride test seam next to the existing video and cancel ones, and asserts what serve hands completion(): required as-is, both object forms flattened to the tool name, absent when unset. Also pins the documented shape of a run whose only tool call failed to parse. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * QVAC-23460 fix: reject a tool_choice naming a reserved mode, cover streaming The SDK packs mode and target into one string, so targeting a tool actually named none collapsed to the none mode: tool calling switched off, the declared-tools check skipped, and a 200 with no sign anything was wrong. The object form still distinguishes the two here, so the collision is rejected at this layer. Streaming built its own argument object on both routes and nothing covered it -- dropping generationParams from either spread left the suite green while tool_choice was dead for the clients that actually stream. Adds a stream: true case per route. Also fills out the responses success cases (required mode, function_call item in the body) and adds one real-model run, which is the only thing that puts tool_choice through the SDK's strict schema and its tools refinement rather than a stub. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * QVAC-23460 test: keep the real-model tool_choice case off a stale prefix Reusing the prompt from the case above hit a kv-cache prefix rendered with thinking on; flipping reasoning_budget under it corrupted the continuation, so the run spent its budget on repeated fragments and finished on length instead of a call. A required tool_choice on a warm cache is fine on its own -- only the changed reasoning_budget is. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * QVAC-23460 test: stop pinning the sampler in the real-model tool_choice case The case exists to prove tool_choice survives the SDK's strict schema and its tools refinement, which the 200 shows. Requiring finish_reason tool_calls made it depend on the shared server's cache state instead: the kv prefix carries turns rendered with thinking on, this request turns it off, and against a stale prefix the run finishes on length. It passed locally and failed in CI on both prompts. The tool name is still checked when a call comes back. The grammar itself is covered deterministically by the addon's integration test. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
#4524 landed on main after the 0.14.0 cut. Cherry-picked onto this branch; the notes need the OpenAI chat/Responses tool_choice surface.
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
2 participants
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.
🎯 What problem does this PR solve?
Cuts
@qvac/cli0.14.0 fromrelease-cli-0.14.0(currentmainat cut time). Follows@qvac/sdk0.20.0. Changelog base is the 0.13.1 backmerge752eddefd.Metadata plus one late pick:
#4524(tool_choiceon the serve OpenAI routes) merged tomainafter the cut, so it is cherry-picked here. Do not publish until@qvac/sdk@0.20.0is on npm.📝 How does it solve it?
0.13.1→0.14.0;@qvac/sdk^0.19.0→^0.20.0#4524(52c7c325d) onto this release head#4389diffusion configure flags,#4428tts-ggml 0.9.x host packages, serve APIs that shipped after the 0.13.1 tag (#4249KV-cache reclaim,#4351MiniMax-H3/v1/videos,#4414TTS 0.8.x load options), and#4524tool_choiceon/v1/chat/completionsand/v1/responses.#4470is infra and omitted fromCHANGELOG_LLM.md^0.20.0@qvac/sdk@0.20.0,@qvac/inference@0.20.0,@qvac/rag@0.8.1,@qvac/llm-llamacpp@0.53.0,@qvac/fabric@0.16.0. Full JS regen still needs published@qvac/sdk@0.20.0.🧪 How was it tested?
--package=cli --base-commit=752eddefd --base-version=0.13.1 --release-type=minorprettier --checkonpackages/cli/CHANGELOG.mdandchangelog/0.14.0/**/*.md#4524already had unit + e2e coverage; cherry-pick applied clean💥 Breaking Changes
qvac configureno longer offersclip_on_cpu/vae_on_cpu/control_net_cpu. Useparams_backend/backend/max_vram/stream_layers.BEFORE:
{ "clip_on_cpu": true, "vae_on_cpu": true, "control_net_cpu": true }AFTER:
{ "params_backend": "te=cpu,vae=cpu", "backend": "controlnet=cpu" }🔌 API Changes
Copied from
changelog/0.14.0/api.md:#4249DELETE /qvac/v1/kv_cache#4351POST /v1/videos(MiniMax-H3)#4414POST /v1/audio/speechTTS 0.8.x load options#4428tts-ggml 0.9.x host packages#4524tool_choiceonPOST /v1/chat/completionsandPOST /v1/responses