Repository navigation
Conversation
…id` (langgenius#3765) Re-attempt of the fix from PR langgenius#3805 (closed, not merged). The bug was unchanged on mainline: cache hit dropped from 97 % to ~75 % on long-instruction agents after upgrading from 0.0.19 to 0.0.20 because the 0.0.20 rewrite started injecting a non-standard ``user_id`` field into ``model_parameters`` while the OAICompat base class was no longer receiving the ``user`` argument (so its OpenAI-standard ``user``-field emission was being skipped too). Two related changes, folded into the same fix: 1. Stop injecting ``model_parameters["user_id"] = user``. The OAICompat base class already emits the OpenAI-standard ``user`` field on the request body, so the legacy ``user_id`` injection was redundant and was the only thing perturbing the upstream cache key. 2. Forward the ``user`` parameter through ``super()._invoke(...)``. The 0.0.20 rewrite had stopped threading the ``user`` argument down to the base class, so the OAICompat ``user``-field emission was being skipped for every DeepSeek call. Forwarding restores the 0.0.19-era contract. Tests (1 updated assertion in ``models/deepseek/tests/test_llm_call.py``): - ``test_invoke_forwards_user_and_omits_user_id_field`` — pins the new contract: ``user`` is forwarded to the base class (so the OpenAI-standard ``user`` field is sent on the request), and ``model_parameters`` must NOT contain ``user_id`` (the field whose addition to the request body was perturbing the cache key). All 34 deepseek tests still pass; 8 opt-in live API tests are skipped without a ``DEEPSEEK_API_KEY``. Bumps the plugin version 0.0.21 → 0.0.22.
GitHub Actions
Failure
|
Please fix the CI errors. @Taranum01 |
|
CI failure was a missing Added a non-empty |
…s#3834) The previous CI run for this PR was failing because the PR body lacked a '## Release Notes' section. That section has since been added, but body edits don't trigger a fresh CI run on their own, so this empty commit re-triggers the workflow to confirm the fix clears the gate. No source changes.
62cc007 to
ef7a319
Compare
|
Status update: the body change (adding Could you either:
The code itself is unchanged from the approved state — the only thing blocking CI was the missing PR-body section, which is now in place. No source changes were made; the merge with |
Taranum01
left a comment
Taranum01
left a comment
There was a problem hiding this comment.
Re-iterating that the ## Release Notes section is now in the PR body (added ~2 hours ago) and the underlying CI failure cause is fixed. The previous failed run was triggered by the missing-body state, and the workflow doesn't re-run on body edits or empty commits. Re-submitting this comment to fire a fresh pull_request_review: submitted event so the workflow re-runs and confirms the fix.
|
Found a way to re-trigger the workflow (a To re-run the actual test on the now-correct body, the maintainer needs to:
Once the test job executes against the current body, the |
This branch had an error being deployed
3 participants
"Fixes #3765\n\n## What problem does this PR solve?\n\nThe 0.0.20 rewrite of the DeepSeek plugin started injecting a non-standard
user_idfield intomodel_parameterswhile the OAICompat base class was no longer receiving theuserargument (so its OpenAI-standarduser-field emission was being skipped too). DeepSeek upstream caches chat-completion requests by their body, and the extrauser_idfield changed the cache key for every request \u2014 cache hit dropped from 97 % to ~75 % on long-instruction agents.\n\nPR #3805 attempted the same fix but was closed without merging. Re-attempting now against the current mainline (which has also picked upapply_dify_headers_if_enabledsince the first attempt).\n\n## What is changed and how it works?\n\nTwo related changes, folded into the same fix:\n\n1. Stop injectingmodel_parameters[\"user_id\"] = user. The OAICompat base class already emits the OpenAI-standarduserfield on the request body, so the legacyuser_idinjection was redundant and was the only thing perturbing the upstream cache key.\n2. Forward theuserparameter throughsuper()._invoke(...). The 0.0.20 rewrite had stopped threading theuserargument down to the base class, so the OAICompatuser-field emission was being skipped for every DeepSeek call. Forwarding restores the 0.0.19-era contract.\n\n## How it was tested?\n\n\n$ uv run pytest tests/ -o addopts=\n34 passed, 8 skipped\n\n\n1 updated test intests/test_llm_call.py:test_invoke_forwards_user_and_omits_user_id_field(renamed fromtest_invoke_uses_official_user_id_and_default_endpoint) pins the new contract:useris forwarded to the base class, andmodel_parametersmust NOT contain auser_idkey (the field whose addition to the request body was perturbing the cache key).\n\n## Release Notes\n\n- fix(deepseek): stop injectingmodel_parameters[\"user_id\"]and forward theuserargument throughsuper()._invoke(...). The 0.0.20 rewrite had (a) added a non-standarduser_idfield to the request body and (b) stopped threading theuserargument down to the OAICompat base class, which is what emits the OpenAI-standarduserfield. (a) alone was perturbing the DeepSeek upstream cache key, dropping cache hit rate from ~97 % to ~75 % on long-instruction agents; (b) was a regression vs the 0.0.19 contract. Bumps the deepseek plugin from 0.0.21 to 0.0.22.\n"