fix: avoid success toast on failed provider test

[Fronut]

Fixes #7933. The Provider page test flow previously reported success based on the HTTP wrapper status, which could show a success toast even when the provider test result was unavailable. This change ensures the success toast only appears when the provider is actually available.

Modifications / 改动点

• Update the non-chat Provider page test flow to validate provider availability before showing a success toast.

• On failure, show a standard error toast to avoid misleading success feedback.

• Core file modified: dashboard/src/views/ProviderPage.vue

• This is NOT a breaking change. / 这不是一个破坏性变更。

Screenshots or Test Results / 运行截图或测试结果

ruff format .
ruff check .

This is the original bug screenshot:

---

Checklist / 检查清单

• 😊 If there are new features added in the PR, I have discussed it with the authors through issues/emails, etc.
  / 如果 PR 中有新加入的功能，已经通过 Issue / 邮件等方式和作者讨论过。

• 👀 My changes have been well-tested, and "Verification Steps" and "Screenshots" have been provided above.
  / 我的更改经过了良好的测试，并已在上方提供了“验证步骤”和“运行截图”。

• 🤓 I have ensured that no new dependencies are introduced, OR if new dependencies are introduced, they have been added to the appropriate locations in requirements.txt and pyproject.toml.
  / 我确保没有引入新依赖库，或者引入了新依赖库的同时将其添加到 requirements.txt 和 pyproject.toml 文件相应位置。

• 😮 My changes do not introduce malicious code.
  / 我的更改没有引入恶意代码。

Summary by Sourcery

Ensure provider test success feedback only appears when the provider is actually available and surface clear error feedback on failures.

Bug Fixes:

• Prevent success toasts from showing when a provider test returns no result or an unavailable status, and instead treat these as failures.

Enhancements:

• Align provider status updates and error handling in the Provider page test flow to consistently reflect backend check results.

[sourcery-ai]

Hey - I've left some high level feedback:

• In testSingleProvider, consider handling the result.status !== 'available' case without throwing (e.g., by updating status and calling showMessage directly) so that exceptions are reserved for genuinely unexpected failures rather than normal unavailability.
• When using result.error for the error toast and error throwing, ensure it is normalized to a user-facing string (e.g., handle cases where the backend might return a non-string error payload) to avoid showing [object Object] or similar in the UI.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In `testSingleProvider`, consider handling the `result.status !== 'available'` case without throwing (e.g., by updating status and calling `showMessage` directly) so that exceptions are reserved for genuinely unexpected failures rather than normal unavailability.
- When using `result.error` for the error toast and error throwing, ensure it is normalized to a user-facing string (e.g., handle cases where the backend might return a non-string error payload) to avoid showing `[object Object]` or similar in the UI.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[gemini-code-assist]

Code Review

This pull request refactors the testSingleProvider function in ProviderPage.vue to improve error handling, response validation, and user feedback via error toasts. The review feedback identifies opportunities to reduce code duplication by moving shared logic to a composable, improve URL construction using axios parameters, and ensure consistent use of translated error messages. A potential issue regarding redundant state updates and metadata loss in the error handling path was also highlighted for correction.

[gemini-code-assist]

The logic in testSingleProvider is largely duplicated with testProvider in useProviderSources.ts. Per the general rules, this core logic (API call, latency calculation, and error handling) should be refactored into a shared helper function in the composable to improve maintainability and ensure consistency across the application.

References

1. Refactor similar functionality into shared helper functions to avoid code duplication.

[gemini-code-assist]

Consider using the params option in axios.get for better URL encoding. Also, use a translated error message instead of a hardcoded English string for consistency with the rest of the application.

    const res = await axios.get('/api/config/provider/check_one', { params: { id: provider.id } })\n    if (!res.data || res.data.status !== 'ok') {\n      throw new Error(res.data?.message || tm('models.testError'))\n    }

[gemini-code-assist]

Use a translated error message here for consistency.

    if (!result) {\n      throw new Error(tm('models.testError'))\n    }

[gemini-code-assist]

While adding an error toast is a good fix, note that providerStatuses might be updated twice if the error was thrown at line 695 (once at line 690 and again at line 710). The second update in the catch block also loses metadata like model and type present in the backend result. Consider refactoring to avoid this redundant update and preserve the full result data.