Skip to content

refactor(config):自定义 Provider 环境变量改造#349

Merged
phantom5099 merged 12 commits into
1024XEngineer:mainfrom
phantom5099:main
Apr 18, 2026
Merged

refactor(config):自定义 Provider 环境变量改造#349
phantom5099 merged 12 commits into
1024XEngineer:mainfrom
phantom5099:main

Conversation

@phantom5099

Copy link
Copy Markdown
Collaborator

PR

完成任务

  1. 完成自定义 Provider 新建链路重构:只保存 api_key_env,不再把 API Key 写入 .env 文件。
  2. 完成 .env 相关实现下线:删除 internal/config/envfile.go 与对应测试,CLI 启动预加载改为 no-op。
  3. 完成创建流程收敛:把“保存 provider 配置 + 持久化环境变量 + 进程变量注入 + 配置重载 + provider 选中”统一收敛到 config/state 服务层。
  4. 完成输入与安全校验增强:新增环境变量名校验、受保护变量拦截、重复 env key 冲突检测、内置 provider 名称冲突检测。
  5. 完成失败回滚闭环:创建流程任一步失败时回滚进程变量、用户级变量、provider 配置,并在回滚后刷新配置快照避免内存态残留。
  6. 完成 UI 交互改造:Provider 新增表单改为显式输入 API Key EnvAPI Key,提交流程改为调用服务层 CreateCustomProvider
  7. 完成非 Windows 平台行为提示:新增平台能力判断,成功后提示“仅当前进程生效,需要自行持久化到 shell profile”。
  8. 完成配置加载健壮性修复:loadCustomProviders 在读取目录失败时不再静默吞错。
  9. 完成 OpenAI-Compatible 发现链路健壮性增强:/modelsdata 字段支持数组与单对象两种格式,异常类型给出显式错误。

使用方案

  1. 架构方案:严格沿用 TUI -> config/state service -> config,避免 UI 侧写配置与回滚逻辑。
  2. 数据方案:
    • Provider 配置文件仅保存 api_key_env
    • 密钥进入用户环境变量与当前进程环境变量,不落地 .env
  3. 事务方案:
    • 服务层统一串行创建流程(互斥锁)。
    • 记录创建前快照并执行可逆回滚。
    • 回滚结束后执行配置重载,确保运行态一致。
  4. 安全方案:
    • 环境变量名格式校验。
    • 受保护变量名单拦截(如 PATH、SYSTEMROOT 等)。
    • 错误信息脱敏,不回显 API Key。
  5. 兼容方案:
    • 非 Windows 平台保留统一接口,返回“无系统级持久化能力”,并通过 UI 活动消息提示用户。
  6. 可测试方案:
    • 为关键服务流新增单测,覆盖成功路径、回滚路径、冲突路径、非法输入路径。
    • 对 provider discovery 的新解析逻辑补齐用例。

达到效果

  1. 密钥不再进入 .env 文件,明文落盘风险下降。
  2. Provider 新建逻辑单点收敛,职责边界更清晰,避免重复设计与跨层副作用。
  3. 创建失败后无残留,运行态与磁盘态一致性提升。
  4. 新增表单输入约束后,API Key Env 的有效性在提交前即可拦截。
  5. 平台差异被显式提示,用户能明确“是否具备持久化能力”。
  6. 配置加载与模型发现链路对异常输入更稳健,降低隐性故障概率。

关键改动文件

  • internal/config/state/service_provider_create.go
  • internal/tui/core/app/update.go
  • internal/config/envvar.go
  • internal/config/env_platform.go
  • internal/config/env_platform_windows.go
  • internal/config/provider_loader.go
  • internal/cli/root.go
  • internal/provider/openaicompat/discovery.go
  • docs/guides/configuration.md

验证结果

  1. 定向模块测试已通过:internal/config/...internal/config/stateinternal/tui/core/app
  2. 全量测试中,internal/security 存在既有失败用例(与本次改造无直接耦合),其余模块可通过。

@codecov

codecov Bot commented Apr 17, 2026

Copy link
Copy Markdown

fennoai[bot]

This comment was marked as outdated.

@phantom5099

Copy link
Copy Markdown
Collaborator Author

/simplify

@fennoai

fennoai Bot commented Apr 17, 2026

Copy link
Copy Markdown
Contributor

结果

已完成你在 /simplify 触发中的要求:先检查并处理未解决 review comment,再做简化审视,并已提交推送。

已完成事项

  1. 阅读历史评论并确认唯一未解决 review comment:internal/config/state/service_provider_create.goproviderCreateFlowMu 为包级全局锁。
  2. 评估后执行修复:将创建流程互斥锁下沉到 Service 实例,避免不同 Service 实例间被全局串行化。
  3. 按要求调用 code-simplifier 子代理复审本次改动;结论为当前实现已足够简洁,无需进一步简化。
  4. 运行测试:go test ./internal/config/state ./internal/config 通过。
  5. 已提交并推送到当前 PR 分支。

代码变更

  • internal/config/state/service.go
    • Service 新增实例字段:createMu sync.Mutex
  • internal/config/state/service_provider_create.go
    • 删除包级 providerCreateFlowMu
    • CreateCustomProvider 改为使用 s.createMu 加锁

提交与推送

未执行项

  • 未对与本次请求无关的其它评论/模块做额外修改。

View job run

xgopilot and others added 2 commits April 17, 2026 15:07
Generated with [codeagent](https://github.com/qbox/codeagent)
Co-authored-by: phantom5099 <245659304+phantom5099@users.noreply.github.com>
fix(config/state): use service-scoped lock for custom provider create
@phantom5099

Copy link
Copy Markdown
Collaborator Author

@xgopilot 针对本次PR,请给我一份给AIreview用的提示词,针对的是修改中所有可能存在的风险点

@phantom5099

Copy link
Copy Markdown
Collaborator Author

@xgopilot 你是资深 Go 代码审查员。请对 PR #349(refactor(config): 自定义 Provider 环境变量改造)做“纯风险导向”审查。

【审查目标】
仅识别问题,不要给正向评价,不要复述 PR 说明。重点关注:安全、回滚一致性、跨平台行为、边界条件、架构边界、回归风险。

【代码范围】
对比基线:origin/main...HEAD
重点文件:

  • internal/config/state/service_provider_create.go
  • internal/config/envvar.go
  • internal/config/env_platform.go
  • internal/config/env_platform_windows.go
  • internal/config/provider_loader.go
  • internal/provider/openaicompat/discovery.go
  • internal/tui/core/app/update.go
  • internal/cli/root.go
    及对应 *_test.go

【必须覆盖的风险检查清单】

  1. 密钥安全
  • 是否存在 API Key 明文落盘、日志回显、错误信息泄漏、panic 泄漏。
  • 错误链路中是否可能把用户输入的 key 带入 error message。
  1. 创建事务与回滚一致性
  • create 流程任一步失败时,process env / user env / provider.yaml 是否都可逆恢复。
  • rollback 失败是否被吞掉;是否会造成“磁盘态与内存态不一致”。
  • rollback 后 reload 失败时的状态是否可预期。
  • 并发下 createMu 是否覆盖完整临界区,是否仍有竞态窗口。
  1. 冲突校验与输入校验
  • APIKeyEnv 合法性、保护变量拦截是否完整(含大小写、空白、平台差异)。
  • provider 名称冲突(builtin/custom)逻辑是否会误判/漏判。
  • env key 重复检测是否大小写一致(尤其 Windows)。
  1. 跨平台行为
  • 非 Windows Persist/Delete/Lookup no-op 是否会导致“看似成功但不可持久化”的误导。
  • Windows registry 读写错误处理是否充分,ErrNotExist 分支是否准确。
  • SupportsUserEnvPersistence 的使用点是否都正确提示用户。
  1. 配置加载与兼容
  • loadCustomProviders 新增错误返回是否引入启动期破坏性回归。
  • provider loader 对目录存在但不可读、符号链接、权限异常等是否处理合理。
  1. OpenAI-compatible /models 解析
  • data 为数组/单对象外,异常类型是否返回可诊断错误。
  • 对非法元素(非对象)当前“跳过”策略是否会静默丢失模型并掩盖问题。
  • HTTP 异常响应与空 body 的错误可观测性是否足够。
  1. TUI -> service 收敛改造
  • UI 是否仍可能绕过 service 直接写配置或注入环境变量。
  • 表单字段(API Key Env / API Key)校验、错误提示、状态清理是否完整。
  • provider add 成功/失败后的状态同步是否可能残留脏状态。
  1. CLI 预加载下线
  • .env 预加载移除后,是否影响其他命令路径(包含 url-dispatch、update、root run)。
  • 相关测试是否只改快照而遗漏行为验证。
  1. 测试充分性
  • 新增测试是否覆盖:成功路径、每个失败点的回滚、冲突路径、非法输入、跨平台分支。
  • 是否存在“只测调用、不测状态”的薄弱断言。

【输出格式】

  • 只输出问题,按严重度排序:Critical / High / Medium / Low。
  • 每条问题必须包含:
    • 标题
    • 严重度
    • 文件与行号(若无法精确到行,给函数名)
    • 触发条件
    • 实际风险(行为后果)
    • 修复建议(最小改动优先)
    • 建议补充的测试点
  • 若未发现问题,明确写“未发现明确缺陷”,并列出“剩余风险与未覆盖场景”。

【审查约束】

  • 不做代码修改。
  • 不输出时间评估。
  • 不输出与风险无关的重构建议。

@phantom5099

Copy link
Copy Markdown
Collaborator Author

High

  1. 事务锁粒度降为 Service 实例级,跨实例并发创建仍有竞态
    严重度: High
    文件与行号: internal/config/state/service.go:18, internal/config/state/service_provider_create.go:64-65 (CreateCustomProvider)
    触发条件: 同一进程内存在多个 state.Service 实例(共享同一个 config.Manager)并发调用 CreateCustomProvider
    实际风险: 冲突检查、快照读取、落盘与回滚不是全局串行,可能出现“互相覆盖/误回滚”(例如 A 回滚删除了 B 刚写入的 provider 目录),导致磁盘态与运行态不一致。
    修复建议: 把互斥提升到 manager 维度(例如在 Manager 内提供 provider-create 事务锁,或恢复进程级统一锁但按 baseDir/manager 做分段)。
    建议补充的测试点: 构造两个 Service 共享同一 Manager 并发创建不同 provider;验证无互相覆盖、无误删除、最终配置一致。
  2. Windows ErrNotExist 判定从 errors.Is 回退为 ==,存在误判分支
    严重度: High
    文件与行号: internal/config/env_platform_windows.go:45,53,70,79
    触发条件: Registry API 返回被包装的“not exist”错误(或未来实现变化导致非同一实例 sentinel)。
    实际风险: 本应幂等成功的 DeleteUserEnvVar/LookupUserEnvVar 被当成失败返回,创建/回滚链路被中断,导致回滚失败放大与状态不一致。
    修复建议: 恢复 errors.Is(err, registry.ErrNotExist) 判定。
    建议补充的测试点: 注入包装后的 ErrNotExist 错误,验证 Delete/Lookup 仍按“不存在即成功/exists=false”处理。

Medium

  1. /models.data 数组内非法元素被静默跳过,易掩盖上游协议异常
    严重度: Medium
    文件与行号: internal/provider/openaicompat/discovery.go:24-30 (decodeModelsData)
    触发条件: 上游返回 data: ["bad", 123, {...}] 或全量非对象元素。
    实际风险: 非法响应被降级为“部分/空模型列表”,诊断信息丢失;上层可能仅表现为“无模型可用”,难定位是协议破坏还是业务无模型。
    修复建议: 对非对象元素返回显式错误(或至少记录并在返回错误中包含非法元素计数/索引)。
    建议补充的测试点: data 数组混合合法与非法元素时应返回可诊断错误;全非法元素时应明确失败而非静默空列表。
  2. .env 预加载直接下线为 no-op,缺少迁移保护,存在启动后凭据缺失回归
    严重度: Medium
    文件与行号: internal/cli/root.go:117-123, internal/cli/root_test.go:1428-1440
    触发条件: 现网用户仍把 key 放在历史 ~/.neocode/.env,且未迁移到系统/进程环境变量。
    实际风险: 启动路径不再加载旧凭据,表现为 provider 鉴权失败;问题对用户不可见且回归面覆盖 root run 等默认入口。
    修复建议: 增加一次性迁移提示/探测(检测到旧 .env 时给出明确错误或迁移指引),至少避免静默失败。
    建议补充的测试点: 存在 legacy .env 且进程环境缺失时,应产生明确可操作提示。

Low

  1. 表单端未拦截受保护环境变量名,校验下沉到异步 service 失败
    严重度: Low
    文件与行号: internal/tui/core/app/update.go:2427-2429 (buildProviderAddRequest), 对照 internal/config/state/service_provider_create.go:173-175
    触发条件: 用户在 UI 输入 PATH/HOME 等受保护变量名。
    实际风险: 提交后才异步失败,错误反馈滞后;与“提交前拦截”目标不一致,增加误操作成本。
    修复建议: 在 buildProviderAddRequest 增加 config.IsProtectedEnvVarName 前置校验。
    建议补充的测试点: API Key Env=PATHsubmitProviderAddForm() 直接返回校验错误且不触发异步命令。

View job run

@xgopilot 只修复第1、2、5个问题,其他问题不许碰,修完提交PR到fork仓库中,而不是直接提交到目前的PR

@fennoai

fennoai Bot commented Apr 17, 2026

Copy link
Copy Markdown
Contributor

已按要求仅修复 1 / 2 / 5,其余问题未改动。

结果

具体修改

  1. 问题 1(并发事务锁粒度)
  • 将自定义 provider 创建锁从 state.Service 实例级提升到 config.Manager 维度:
    • internal/config/manager.go 新增 providerCreateMuLockProviderCreate/UnlockProviderCreate
    • internal/config/state/service_provider_create.go 改为使用 s.manager 级别锁
    • internal/config/state/service.go 移除 createMu
  • 新增并发回归测试(两个 Service 共享同一 Manager)验证串行化生效:
    • internal/config/state/service_provider_create_test.go
  1. 问题 2(Windows ErrNotExist 判定)
  • internal/config/env_platform_windows.goDeleteUserEnvVar/LookupUserEnvVar 的 not-exist 判定改为 errors.Is
  • 新增 Windows 测试覆盖包装错误场景:
    • internal/config/env_platform_windows_test.go
  1. 问题 5(UI 前置拦截受保护环境变量)
  • internal/tui/core/app/update.gobuildProviderAddRequest 增加 config.IsProtectedEnvVarName 提交前校验。
  • 新增测试:
    • internal/tui/core/app/update_test.go
    • 覆盖 buildProviderAddRequest 直接返回 protected 错误
    • 覆盖 submitProviderAddForm()API Key Env=PATH 时直接失败且不触发异步 cmd

验证

  • go test ./internal/config/state ./internal/tui/core/app ./internal/config 通过
  • GOOS=windows GOARCH=amd64 go test ./internal/config -run TestIsWindowsRegistryNotExist -c 编译通过(windows 相关代码编译校验)

View job run

xgopilot and others added 2 commits April 17, 2026 15:24
Generated with [codeagent](https://github.com/qbox/codeagent)
Co-authored-by: phantom5099 <245659304+phantom5099@users.noreply.github.com>
fix(config): 修复 provider 创建并发锁与前置校验
@phantom5099

Copy link
Copy Markdown
Collaborator Author

@xgopilot 针对本次PR,请给我一份给AIreview用的提示词,针对的是修改中所有可能存在的风险点

@phantom5099

Copy link
Copy Markdown
Collaborator Author

@xgopilot 你是资深 Go 代码审查员。请对 PR #349(refactor(config): 自定义 Provider 环境变量改造)执行“纯风险导向”审查。

【审查输入】

  • 仓库:1024XEngineer/neo-code
  • 对比范围:origin/main...HEAD
  • 重点目录:internal/config、internal/provider/openaicompat、internal/tui/core/app、internal/cli
  • 核心目标:只识别缺陷与风险,不给正向评价,不复述 PR 描述。

【必须检查的高风险面】

  1. 密钥安全与脱敏
  • API Key 是否在任何路径落盘(配置、日志、错误、快照、测试夹具)。
  • 错误包装/活动消息/panic 是否可能泄漏明文 key、baseDir、敏感路径。
  • sanitize 逻辑是否覆盖字符串替换遗漏(大小写、路径分隔、多次出现、嵌套 error)。
  1. 创建流程原子性与回滚闭环(service_provider_create)
  • CreateCustomProvider 各步骤失败时,process env / user env / provider.yaml 是否都可逆。
  • 回滚失败是否被合并并上抛,是否存在“主错误被覆盖”或“回滚错误丢失”。
  • 回滚后的 reload 失败是否导致内存态与磁盘态不一致。
  • 快照恢复是否误删非目标目录、权限异常时是否有可诊断错误。
  1. 并发与竞态
  • create 互斥锁是否覆盖完整临界区(读快照->写入->reload->select)。
  • 多 goroutine 并发创建同名 provider/同 env key 时是否仍有 TOCTOU 窗口。
  • manager.Get()/Reload()/SelectProvider 交互是否可能出现可见性问题。
  1. 输入校验与冲突检测
  • APIKeyEnv 校验:空白、非法字符、大小写、平台差异。
  • 受保护变量名单是否可绕过(大小写、前后空白)。
  • builtin/custom provider 名称冲突是否误判或漏判。
  • env key 去重在 Windows 大小写不敏感场景是否一致。
  1. 跨平台语义一致性(env_platform*)
  • 非 Windows no-op 持久化是否产生“看似成功但未持久化”的误导。
  • SupportsUserEnvPersistence 的提示触发点是否完整且仅在必要时提示。
  • Windows 注册表 ErrNotExist 判断是否可靠,其他异常是否被误吞。
  1. 配置加载与兼容回归(provider_loader/manager)
  • loadCustomProviders 读取目录失败从“静默”改“报错”后,是否引入启动中断回归。
  • providers 目录异常(权限、符号链接、损坏 yaml)的错误可观测性。
  • 删除 envfile 相关实现后,历史配置迁移路径是否出现断档。
  1. OpenAI-compatible 模型发现(discovery)
  • /models.data 支持 array/object 后,非法类型是否返回可诊断错误。
  • 数组中非法元素“跳过”是否导致静默丢模型,是否应至少记录告警。
  • HTTP 错误/空 body/非 JSON 响应下的错误信息是否足够定位问题。
  1. TUI -> Service 收敛改造(update.go)
  • UI 是否仍有绕过 service 直接写配置/改环境变量的路径。
  • 表单校验是否前后一致(UI 校验 vs service 校验)并避免双重标准。
  • 提交失败后状态清理是否完整(submitting、error、activity、picker 状态)。
  • 成功后 provider/model 切换与刷新是否可能残留脏状态。
  1. CLI 预加载变更(root.go)
  • .env 预加载下线后,root/url-dispatch/update 路径行为是否保持预期。
  • runGlobalPreload no-op 是否掩盖了原有失败信号。
  1. 测试质量与缺口
  • 是否覆盖每个失败注入点(save/persist/setenv/reload/select/rollback分支)。
  • 是否覆盖跨平台分支与大小写冲突。
  • 是否存在“只断言 error,不断言状态恢复结果”的薄弱用例。
  • 特别关注 Codecov 报告提到的低覆盖文件是否存在未测分支风险。

【输出要求】

  • 仅输出问题,按严重度排序:Critical / High / Medium / Low。
  • 每条问题必须包含:
    1. 标题
    2. 严重度
    3. 位置(文件:行号;无法精确则函数名)
    4. 触发条件
    5. 实际风险/后果
    6. 最小修复建议
    7. 建议补充测试点
  • 若无明确缺陷:写“未发现明确缺陷”,并列出“剩余风险与未覆盖场景”。

【约束】

  • 不修改代码。
  • 不输出工时/时间评估。
  • 不给与风险无关的重构建议。
  • 不输出正向评价。

@phantom5099

Copy link
Copy Markdown
Collaborator Author
  1. 创建流程在 SaveCustomProvider 失败时没有执行回滚,可能残留脏目录/半成品文件

@xgopilot 只修复创建流程在 SaveCustomProvider 失败时没有执行回滚,可能残留脏目录/半成品文件和创建流程仅使用进程内互斥,缺少跨进程/跨 Manager 实例并发保护,存在 TOCTOU 窗口两个问题

@fennoai

fennoai Bot commented Apr 17, 2026

Copy link
Copy Markdown
Contributor

完成结果

已按你的要求仅修复这两个问题:

  1. SaveCustomProvider 失败时未回滚,可能残留脏目录/半成品文件。
  2. 创建流程仅进程内互斥,缺少跨进程/跨 Manager 实例并发保护(TOCTOU 窗口)。

变更内容

  • internal/config/state/service_provider_create.go
    • 新增 saveCustomProviderForCreate 可替换入口(用于覆盖 Save 失败回滚测试)。
    • 新增跨进程创建锁:lockProviderCreateCrossProcess(...),基于 baseDir/.provider-create.lock 目录锁轮询获取。
    • CreateCustomProvider 中接入跨进程锁(与现有 manager.LockProviderCreate 共同生效)。
    • SaveCustomProvider 失败改为进入统一 rollback(...),确保清理可能产生的脏目录并刷新配置快照。
  • internal/config/state/service_provider_create_test.go
    • 新增 TestCreateCustomProviderRollbackOnSaveProviderFailure:覆盖 Save 失败后目录与状态回滚。
    • 新增 TestCreateCustomProviderSerializesAcrossManagersSharingBaseDir:覆盖不同 Manager 共享同一 baseDir 时的串行化。
    • 更新测试 stub,支持还原 saveCustomProviderForCreate

验证

  • 已执行并通过:go test ./internal/config/state ./internal/config

提交与推送

未执行

  • 未扩展处理你本次要求以外的问题。

View job run

xgopilot and others added 2 commits April 17, 2026 15:43
…ate lock

Generated with [codeagent](https://github.com/qbox/codeagent)
Co-authored-by: phantom5099 <245659304+phantom5099@users.noreply.github.com>
fix(config): 补齐创建流程回滚与跨进程并发保护
@fennoai fennoai Bot mentioned this pull request Apr 17, 2026
@phantom5099

Copy link
Copy Markdown
Collaborator Author

/review

@fennoai fennoai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found 2 noteworthy issues after code quality/performance/security/doc checks.

  • 1 high-severity availability issue in cross-process locking.
  • 1 medium-severity UX/diagnostics issue in timeout error mapping.

func lockProviderCreateCrossProcess(ctx context.Context, baseDir string) (func(), error) {
lockPath := filepath.Join(baseDir, providerCreateCrossProcessLockName)
for {
if err := os.Mkdir(lockPath, 0o700); err == nil {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

High · Availability

This lock implementation can deadlock provider creation after an unclean exit. If a process crashes after creating .provider-create.lock, later runs will keep waiting until context timeout and never recover automatically.

Please add stale-lock recovery (for example: lock metadata with PID/start time + liveness check, or mtime-based lease/expiry) so a leftover lock directory does not permanently block CreateCustomProvider.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xgopilot 仅修复这个问题

@fennoai fennoai Bot Apr 17, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

完成情况

已按“仅修复这个问题”完成单点修复:处理 internal/config/state/service_provider_create.go 中跨进程目录锁在异常退出后遗留导致后续创建流程持续等待直至超时的问题。

本次改动

  • internal/config/state/service_provider_create.go
    • .provider-create.lock 增加租约文件与心跳续租。
    • 在锁竞争时增加“陈旧锁回收”逻辑:超出阈值的锁目录会被自动回收后重试获取。
    • 获取锁后初始化租约,释放锁时先停止心跳再清理锁目录。
  • internal/config/state/service_provider_create_test.go
    • 新增 TestLockProviderCreateCrossProcessReclaimsStaleLock:验证可回收陈旧锁并继续创建。
    • 新增 TestLockProviderCreateCrossProcessWaitsForFreshLockUntilContextDone:验证新鲜锁不会被误回收,仍按上下文超时退出。

验证

  • 通过:go test ./internal/config/state

提交与推送

未执行

  • 未修改你未要求的其他问题(包括超时错误提示文案等)。

View job run

})
if err != nil {
err = rollback(processEnvApplied, userEnvPersisted, envPersisted, providerSaved, err)
if errors.Is(err, context.DeadlineExceeded) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Medium · Error diagnosis regression

All context.DeadlineExceeded errors are rewritten as model discovery timeout, but this flow now also includes cross-process lock waiting and pre-discovery steps. When timeout comes from lock contention/stale lock, the current message is misleading (check base URL, API key, and network).

Please preserve the original stage (or add stage-aware timeout wrapping in CreateCustomProvider) so users get actionable guidance.

xgopilot and others added 2 commits April 17, 2026 16:33
Generated with [codeagent](https://github.com/qbox/codeagent)
Co-authored-by: phantom5099 <245659304+phantom5099@users.noreply.github.com>
fix(config/state): recover stale provider-create lock
@phantom5099 phantom5099 merged commit 70ca85e into 1024XEngineer:main Apr 18, 2026
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants