[good first issue] fix(offload): resolve local-llm apiKey from auth-profile store as fallback#150
Open
MicroGery wants to merge 2 commits into
Open
Conversation
…lback When offload.model references a provider whose apiKey is managed via OpenClaw's auth-profiles mechanism (the recommended default, e.g. set up with 'openclaw auth'), the local-llm initializer previously only read models.providers[provider].apiKey in the config tree. If the key was absent there, LocalLlmClient construction was skipped and L1/L1.5/L2 were disabled with a misleading "missing apiKey" error -- even though the key existed and the main agent model worked fine. Fix: add src/offload/auth-profile-key.ts, a synchronous helper that loads the auth-profile store via openclaw/plugin-sdk/provider-auth and returns the first api_key-type credential for the provider. The helper is guarded with try/catch so older OpenClaw versions that do not expose this SDK subpath degrade silently to the previous behavior. In index.ts, the apiKey lookup becomes: providerCfg?.apiKey ?? resolveApiKeyFromAuthProfile(api, providerKey, logger) registerOffload() keeps its synchronous contract; no race is introduced around backendClient assignment. Closes TencentCloud#90 Signed-off-by: MicroGrey <changyuhang@outlook.com>
Collaborator
|
Thank you for participating in our good first issue event, we will complete the review internally as soon as possible! |
Collaborator
|
感谢提供PR,麻烦补充下单测吧,我们尽快合入 |
Author
好的,我来补充一下测试用例 |
Add unit tests for resolveApiKeyFromAuthProfile covering the four resolution branches: api_key profile returns the plaintext key, oauth/token-only providers return undefined, providers with no profile return undefined, and keyRef-only (no plaintext) profiles are skipped. Also covers the older-host case where the provider-auth SDK subpath is unavailable. To keep the test self-contained (no real OpenClaw install or on-disk auth-profile store), resolveApiKeyFromAuthProfile gains an optional fourth parameter to inject a fake provider-auth SDK loader. Production callers pass three arguments and keep loading the real SDK via require. Signed-off-by: MicroGrey <changyuhang@outlook.com>
Author
请检视 |
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.
Description | 描述
当
offload.model引用的 provider 通过 OpenClaw 的 auth-profiles 机制管理密钥时(即使用openclaw auth录入,OpenClaw 推荐的默认方式),local-llm 初始化逻辑只从models.providers[provider].apiKey(配置树明文)读取密钥。如果密钥不在配置树里,
LocalLlmClient构建被跳过,L1/L1.5/L2 全部禁用,并报出误导性的missing apiKey错误——即便主对话用同一个 provider 正常运行。修复方案:
新增
src/offload/auth-profile-key.ts,一个同步 helper:openclaw/plugin-sdk/provider-auth加载 auth-profile storeapi_key类型的 credential,返回明文 key在
index.ts中,apiKey 取值改为:providerCfg?.apiKey ?? resolveApiKeyFromAuthProfile(api, providerKey, logger)registerOffload()维持同步契约,backendClient赋值线程安全、无竞争。Related Issue | 关联 Issue
Fix #90
Change Type | 修改类型
Self-test Checklist | 自测清单
修复后检查日志:[context-offload] [local-llm] Initialized: model=mimo-v2-pro, baseUrl=https://api.xiaomimimo.com/v1