[GH-ISSUE #220] [Bug]: User-defined Qwen provider is ignored when name matches built-in provider #82

New Issue

2026-06-06T22:09:01-04:00

yindo commented

2026-06-06 22:09:01 -04:00

Originally created by @jtomkh2-dot on GitHub (Mar 20, 2026).
Original GitHub issue: https://github.com/vxcontrol/pentagi/issues/220

Originally assigned to: @asdek on GitHub.

Affected Component

AI Agents (Researcher/Developer/...)

Describe the bug

When creating a user-defined Qwen provider in Settings > Providers with the name "qwen", the default embedded
provider takes precedence over the user-defined one. The GetProvider() function in providers.go uses a switch
statement that matches all built-in provider names first, including "qwen", before checking the database. This
means user-defined providers with names matching built-in providers are never used.

Steps to Reproduce

Configure QWEN_API_KEY in .env
Start PentAGI - the default "qwen" provider is available
Go to Settings > Providers and create a new Qwen provider named "qwen" with custom model config (e.g., change model to "qwen3.5-plus")
Create a flow using the "qwen" provider
The flow still uses the built-in default model (qwen3.5-flash) instead of the custom config from the database

Expected Behavior

User-defined providers should take precedence over default/embedded providers when names match.

Code Location

File: pentagi/backend/pkg/providers/providers.go
Function: GetProvider() at line 677
Issue: The switch statement at lines 683-704 matches DefaultProviderNameQwen before checking the database at line 707

Current Logic (Bug)

func (pc *providerController) GetProvider(
    ctx context.Context,
    prvname provider.ProviderName,
    userID int64,
) (provider.Provider, error) {
    // Lookup default providers first
    switch prvname {
    case provider.DefaultProviderNameOpenAI:
        return pc.Providers.Get(provider.DefaultProviderNameOpenAI)
    // ... other cases ...
    case provider.DefaultProviderNameQwen:           // ← "qwen" matches here
        return pc.Providers.Get(provider.DefaultProviderNameQwen)  // ← returns built-in, never checks DB
    }

    // Lookup user defined providers by name and build it
    prv, err := pc.db.GetUserProviderByName(...)     // ← never reached for "qwen"
}

System Configuration

PentAGI Version：1.2.0
docker Version: 27.5.1+dfsg4
Docker Compose version 2.32.4-3

Logs and Artifacts

No response

Screenshots or Recordings

No response

Verification

I have checked that this issue hasn't been already reported
I have provided all relevant configuration files (with sensitive data removed)
I have included relevant logs and error messages
I am running the latest version of PentAGI

Originally created by @jtomkh2-dot on GitHub (Mar 20, 2026). Original GitHub issue: https://github.com/vxcontrol/pentagi/issues/220 Originally assigned to: @asdek on GitHub. ### Affected Component AI Agents (Researcher/Developer/...) ### Describe the bug When creating a user-defined Qwen provider in Settings > Providers with the name "qwen", the default embedded provider takes precedence over the user-defined one. The GetProvider() function in providers.go uses a switch statement that matches all built-in provider names first, including "qwen", before checking the database. This means user-defined providers with names matching built-in providers are never used. ### Steps to Reproduce 1. Configure `QWEN_API_KEY` in `.env` 2. Start PentAGI - the default "qwen" provider is available 3. Go to Settings > Providers and create a new Qwen provider named "qwen" with custom model config (e.g., change model to "qwen3.5-plus") 4. Create a flow using the "qwen" provider 5. The flow still uses the built-in default model (qwen3.5-flash) instead of the custom config from the database ## Expected Behavior User-defined providers should take precedence over default/embedded providers when names match. ## Code Location - **File**: `pentagi/backend/pkg/providers/providers.go` - **Function**: `GetProvider()` at line 677 - **Issue**: The switch statement at lines 683-704 matches `DefaultProviderNameQwen` before checking the database at line 707 ### Current Logic (Bug) ```go func (pc *providerController) GetProvider( ctx context.Context, prvname provider.ProviderName, userID int64, ) (provider.Provider, error) { // Lookup default providers first switch prvname { case provider.DefaultProviderNameOpenAI: return pc.Providers.Get(provider.DefaultProviderNameOpenAI) // ... other cases ... case provider.DefaultProviderNameQwen: // ← "qwen" matches here return pc.Providers.Get(provider.DefaultProviderNameQwen) // ← returns built-in, never checks DB } // Lookup user defined providers by name and build it prv, err := pc.db.GetUserProviderByName(...) // ← never reached for "qwen" } ``` ### ### System Configuration PentAGI Version：1.2.0 docker Version: 27.5.1+dfsg4 Docker Compose version 2.32.4-3 ### Logs and Artifacts _No response_ ### Screenshots or Recordings _No response_ ### Verification - [x] I have checked that this issue hasn't been already reported - [x] I have provided all relevant configuration files (with sensitive data removed) - [ ] I have included relevant logs and error messages - [x] I am running the latest version of PentAGI

yindo added the bug label 2026-06-06 22:09:01 -04:00

yindo closed this issue

2026-06-06 22:09:01 -04:00

yindo commented

2026-06-06 22:09:02 -04:00

@JasonOA888 commented on GitHub (Mar 22, 2026):

I checked the current main branch. The fix has already been applied in commit e05062e (PR #222).

The GetProvider function now checks user-defined providers first, then falls back to default providers. This matches the expected behavior - user-defined providers take precedence over built-in defaults.

This issue can probably be closed.

@JasonOA888 commented on GitHub (Mar 22, 2026): I checked the current `main` branch. The fix has already been applied in commit e05062e (PR #222). The `GetProvider` function now checks user-defined providers first, then falls back to default providers. This matches the expected behavior - user-defined providers take precedence over built-in defaults. This issue can probably be closed.

yindo commented

2026-06-06 22:09:02 -04:00

@asdek commented on GitHub (Mar 22, 2026):

hey @JasonOA888 @jtomkh2-dot

@JasonOA888 you are right it should be expected behavior after the latest changes

@jtomkh2-dot could you update the product and check it on the your installation?
docker compose pull && docker compose up -d

@asdek commented on GitHub (Mar 22, 2026): hey @JasonOA888 @jtomkh2-dot @JasonOA888 you are right it should be expected behavior after the latest changes @jtomkh2-dot could you update the product and check it on the your installation? `docker compose pull && docker compose up -d`

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: vxcontrol/pentagi#82