fix: 供应商分组过滤逻辑优化，隐藏无关分组的供应商

[Hwwwww-dev]

Summary

Optimizes the provider group filtering logic to ensure providers outside the user's configured groups are completely hidden from view, making the decision context cleaner and more accurate for debugging and monitoring.

Problem

After the key-level provider group feature was implemented (#281, #296), providers outside the user's group were still being recorded in the filteredProviders list (decision chain logs). This caused:

1. Misleading metrics: totalProviders and enabledProviders counts included providers the user shouldn't see
2. Noisy decision logs: Users saw "filtered out" entries for providers they were never supposed to access
3. Information leakage: Decision chain exposed existence of providers from other groups

Related Issues:

• Follow-up to feat:增加在新建令牌时选择供应商分组的功能 #281 - Key-level provider group feature
• Follow-up to PR fix: key provider group #281 #296 - Provider group bug fixes

Solution

Move group filtering to Step 1 (before all other filtering steps), treating it as a "silent pre-filter" that:

1. Creates a visibleProviders subset from allProviders based on user/key group configuration
2. Only providers in this subset are considered for subsequent filtering steps
3. totalProviders/enabledProviders now reflect only user-visible counts
4. Providers excluded by group are never recorded in filteredProviders

Filtering order change:

• Before: Basic filter → Format match → Model match → Group filter → Health check → Priority → Selection
• After: Group pre-filter → Basic filter → Format match → Model match → Health check → Priority → Selection

Backward compatible: Users without configured groups still see all providers (global scan behavior preserved).

Changes

Core Changes

• src/app/v1/_lib/proxy/provider-selector.ts: Restructured filtering pipeline
  • Added Step 1: Group pre-filter (silent) before all other filters
  • Changed all subsequent steps to operate on visibleProviders instead of allProviders
  • Updated decision context initialization to use filtered counts
  • Adjusted step numbering (Step 2-6 instead of Step 1-5)

Behavior Changes

Scenario	Before	After
User with groups	Sees all providers in filteredProviders	Only sees providers in their groups
totalProviders count	All providers in DB	Only user-visible providers
No matching group providers	Returns null with full context	Returns null with empty context (groupFilterApplied: true)

Testing

Manual Testing

1. Create user with specific provider groups (e.g., "group-a")
2. Create providers with different groupTags ("group-a", "group-b")
3. Make API request with user's key
4. Check decision chain logs:
   • Verify totalProviders only counts "group-a" providers
   • Verify filteredProviders doesn't include "group-b" providers

Edge Cases

• User without providerGroup set → All providers visible (backward compat)
• Key overrides user group → Key's group takes priority
• No providers in user's group → Returns null with appropriate error

Checklist

• Code follows project conventions
• Self-review completed
• Tests pass locally
• Backward compatible with existing configurations

---

Description enhanced by Claude AI

[gemini-code-assist]

Summary of Changes

Hello @Hwwwww-dev, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

此拉取请求通过将基于分组的供应商过滤逻辑前置，显著优化了供应商选择流程。核心目标是确保用户仅能访问其所属分组中明确指定的供应商，从而增强了系统的安全性和相关性。通过在初始阶段执行分组过滤，系统能够更准确地反映用户实际可用的供应商集合，简化了后续的过滤步骤，并避免了处理不相关的供应商。

Highlights

• 分组过滤前置: 将供应商分组过滤逻辑提前至所有其他过滤步骤之前（作为第一步），确保只有用户所属分组的供应商才会被考虑。
• 统计数据准确性: totalProviders 和 enabledProviders 现在只统计用户可见（即经过分组过滤后）的供应商，提高了统计的准确性。
• 严格分组隔离: 如果用户指定的分组中没有可用的供应商，系统将立即返回空结果，而不是尝试回退到其他供应商。
• 过滤流程优化: 移除了原有的第二步分组过滤逻辑，简化了后续的过滤流程，并更新了日志中的步骤编号。

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

本次 PR 优化了供应商分组的过滤逻辑，将分组过滤提前到所有过滤步骤之前，使得后续的统计和过滤都基于用户可见的供应商池。这修复了之前分组过滤在后，导致统计数据不准确以及无关供应商被记录的问题。

代码重构清晰地反映了新的逻辑流程，将原有的 Step 2 移至 Step 1，并相应调整了后续步骤。整体实现与 PR 描述一致，逻辑正确。

我提出了一个关于代码复用的建议，通过提取辅助函数来消除重复的标签解析逻辑，以提高代码的可维护性。

[gemini-code-assist]

这部分代码中，处理逗号分隔标签的逻辑（split, map, filter）在两个地方重复了。为了提高代码的可维护性和复用性，建议将此逻辑提取到一个辅助函数中。

      const parseTags = (tags: string): string[] => {
        return tags.split(",").map((t) => t.trim()).filter(Boolean);
      };

      const groups = parseTags(effectiveGroupPick);

      const groupFiltered = allProviders.filter((p) => {
        if (!p.groupTag) return false;
        const providerTags = parseTags(p.groupTag);
        return providerTags.some((tag) => groups.includes(tag));
      });

[github-actions]

Code Review Summary

No significant issues identified in this PR. The changes correctly move group filtering to be a pre-filter step (Step 1), ensuring that users only see providers within their assigned groups. The logic changes are well-structured and the implementation achieves the stated goal of provider group visibility isolation.

PR Size: S

• Lines changed: 151 (77 additions, 74 deletions)
• Files changed: 1

Review Coverage

• Logic and correctness - Clean
• Security (OWASP Top 10) - Clean
• Error handling - Clean
• Type safety - Clean
• Documentation accuracy - Clean
• Test coverage - No tests for ProxyProviderResolver (pre-existing)
• Code clarity - Good

Notes

• The refactoring correctly ensures visibleProviders is used consistently after group pre-filtering
• Error handling properly returns null with appropriate context when user's group has no providers
• Step numbering was appropriately updated to reflect the new order (Steps 1-6)
• Logging maintains consistency with the new filtering approach

---

Automated review by Claude AI