Skip to content

fix(settings): 用当前模型验证连接#187

Merged
H-Chris233 merged 4 commits into
Open-Less:mainfrom
H-Chris233:main
May 2, 2026
Merged

fix(settings): 用当前模型验证连接#187
H-Chris233 merged 4 commits into
Open-Less:mainfrom
H-Chris233:main

Conversation

@H-Chris233
Copy link
Copy Markdown
Collaborator

摘要

Fixes #136

本 PR 修复设置页“连接检查”只验证鉴权或模型列表,无法覆盖当前选中 LLM 模型真实调用路径的问题。

此前用户可能遇到一种情况:模型列表可以正常拉取,API Key / Endpoint 看起来配置正确,但实际语音识别后的润色阶段仍然失败。原因是“验证”入口没有真正调用当前选中的 LLM 模型,只能证明鉴权或模型枚举接口可用,不能证明当前模型可用于 chat-completion / polish 流程。

本次改动让 LLM 连接检查直接使用当前保存的模型 ID 执行一次真实 polish 探测。模型枚举仍保留在独立的“拉取模型”入口中,避免把“验证当前模型可用”和“列出可用模型”两个行为混在一起。

修复 / 新增 / 改进

  • 调整 validate_provider_credentials 行为:

    • llm 验证改为执行当前选中模型的真实调用探测
    • asr 验证继续走现有模型列表 / 鉴权检查路径
  • 新增 LLM 验证路径:

    • 读取当前 LLM provider 配置
    • 读取当前保存的模型 ID
    • 构造 OpenAI-compatible LLM provider
    • 使用当前模型执行一次 polish 探测
  • 保留独立“拉取模型”流程:

    • 模型列表发现仍由 fetch-models 入口处理
    • 连接验证不再返回 model count
    • UI 不再把验证成功和模型数量发现混为一谈
  • 简化前端验证结果:

    • 验证通过时显示“连接检查通过”
    • 不再显示“可用模型 N 个”
    • 模型数量仍只在“拉取模型”动作中展示
  • 更新 IPC 类型:

    • ProviderCheckResult 移除 modelCount
    • mock 返回值同步改为 { ok: true }
  • 更新中英文 i18n 文案:

    • 说明文字改为“验证当前模型连通性或拉取模型”
    • 验证成功文案改为“连接检查通过”

兼容

  • 不包含:

    • 不重构 provider 架构。
    • 不合并“验证”和“拉取模型”两个流程。
    • 不移除手动填写模型 ID 的能力。
    • 不改变模型列表拉取逻辑。
    • 不改变正常 polish 调用路径。
    • 不引入新依赖。
    • 不在日志或 UI 中暴露明文 API Key。
  • 对现有用户 / 本地环境 / 构建流程的影响:

    • 设置页 LLM 验证更接近真实润色调用路径。
    • 如果 API Key 能拉模型列表、但当前模型不可用于实际 chat-completion,验证阶段会更早暴露问题。
    • 用户仍可以单独点击“拉取模型”查看可用模型列表。
    • 手动填写模型 ID 的方式保持不变。
    • 构建流程无变化。

H-Chris233 added 2 commits May 2, 2026 00:10
The settings validation button now uses the currently selected LLM model for a real chat-completion probe instead of only listing models/auth state. The frontend message was simplified to reflect validation success without conflating it with model-count discovery, which remains handled by the dedicated fetch-models action.

Constraint: Keep the change minimal and local; preserve the separate fetch-models workflow for listing available models.
Rejected: Keep auth-only validation | it would keep missing the failure mode reported in issue Open-Less#136.
Rejected: Add a broader provider refactor | unnecessary for the narrow validation behavior change.
Confidence: high
Scope-risk: narrow
Directive: Validation should probe the selected model path; model enumeration belongs to fetch-models.
Tested: npm ci; npm run build; cargo test --lib
Not-tested: Live provider endpoint behavior against real credentials on the user’s machine
Copy link
Copy Markdown

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

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

Sorry @H-Chris233, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

@H-Chris233 H-Chris233 self-assigned this May 2, 2026
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a259b57d5e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

.polish("验证连接", PolishMode::Raw, &[], &[], None)
.await
.map(|_| ())
.map_err(|e| e.to_string())
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P2 Badge Preserve HTTP status marker for LLM validation errors

When validate_llm_provider maps LLMError with e.to_string(), non-2xx provider responses become strings like invalid response: status 401... instead of the existing providerHttpStatus:<code> format used elsewhere. In the settings flow, providerErrorMessage only recognizes the providerHttpStatus: prefix, so bad API key/model/endpoints now show a generic failure instead of the specific HTTP-status guidance, which regresses diagnosability for real connection failures.

Useful? React with 👍 / 👎.

LLM validation now maps non-2xx completion responses back to the same providerHttpStatus:<code> marker used by the model-listing path. That keeps the settings page on its existing error-copy branch so real API-key, endpoint, and model failures stay diagnosable instead of collapsing into a generic message.

Constraint: Keep the change minimal and preserve the existing settings error-message parser.
Rejected: Teach the frontend to parse LLMError::InvalidResponse text | this would duplicate provider-status semantics and broaden the UI change.
Confidence: high
Scope-risk: narrow
Directive: Validation error strings for provider status should stay normalized at the command boundary.
Tested: cargo test --lib
Not-tested: Live provider error text against a real non-2xx endpoint
@chatgpt-codex-connector
Copy link
Copy Markdown

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

@Open-Less Open-Less deleted a comment from github-actions Bot May 2, 2026
@Open-Less Open-Less deleted a comment from github-actions Bot May 2, 2026
@Open-Less Open-Less deleted a comment from github-actions Bot May 2, 2026
@H-Chris233
Copy link
Copy Markdown
Collaborator Author

/review

@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 2, 2026

PR Reviewer Guide 🔍

(Review updated until commit e996199)

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis ✅

136 - PR Code Verified

Compliant requirements:

  • 修复语音识别后润色失败的问题(即使 LLM 配置看起来正确)
  • 验证连接时能检测导致润色失败的真实原因

Requires further human verification:

  • 设置中 LLM 验证流程的 UI 测试
  • 完整语音识别 + 润色的端到端测试
⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪
🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review

Possible Issue

LLM 验证使用硬编码测试 prompt '验证连接' 且参数为空切片;若 API 对过短或 trivial 的输入拒绝或返回异常响应,验证可能失败,而真实润色场景(更长的实际文本)仍可正常工作,导致用户误判模型不可用。

.polish("验证连接", PolishMode::Raw, &[], &[], None)

The LLM connection check no longer falls back to an Ark-specific default model when the user has not configured one. Instead, it returns a dedicated marker and the settings UI surfaces the empty-state copy, which keeps the validation result aligned with the actual configuration state.

Constraint: Preserve the existing provider-status parsing and keep the change minimal.
Rejected: Keep the deepseek-v3-2 fallback | it creates a false positive for unconfigured non-Ark providers.
Confidence: high
Scope-risk: narrow
Directive: Validation should never invent a model when the user has not saved one.
Tested: npm run build; cargo test --lib
Not-tested: Live provider behavior with a truly empty model field on a real endpoint
@H-Chris233
Copy link
Copy Markdown
Collaborator Author

/review

@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 2, 2026

Persistent review updated to latest commit e996199

@H-Chris233 H-Chris233 merged commit dbd0503 into Open-Less:main May 2, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

润色失败

1 participant