fix: batch key queries in list_team to eliminate N+1

[CAFxX]

Summary

• The list_team endpoint issued one find_many query per team to fetch verification token keys, causing an N+1 query problem
• With many teams and ~163 keys per team on average, this generates significant database load
• Replace the per-team loop with a single batched IN query, then distribute keys in-memory

The existing @@index([team_id]) on LiteLLM_VerificationToken already supports this query efficiently.

Test plan

• Added test_list_team_batches_key_queries verifying:
  • find_many is called exactly once with an IN query (not once per team)
  • Keys are correctly distributed to their respective teams
  • Teams with no keys get an empty list

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Error		Mar 11, 2026 6:20pm

[greptile-apps]

Greptile Summary

This PR fixes an N+1 database query problem in the /team/list endpoint by replacing a per-team find_many loop with a single batched IN query, then distributing the results in-memory.

Changes:

• team_endpoints.py: Replaces the per-team loop that issued one DB query per team with a single batch find_many call (WHERE team_id IN (...)), then builds a _keys_by_team dict for O(1) lookup during the response loop.
• test_team_endpoints.py: Adds test_list_team_batches_key_queries using AsyncMock/MagicMock to assert that find_many is called exactly once with the IN query (not once per team) and that keys are correctly distributed to their respective teams, including teams with no keys.

Correctness: The logic is straightforward and correct. The existing @@index([team_id]) on LiteLLM_VerificationToken efficiently supports the new batched query. The test is well-structured and verifies the main invariant (single batched call + correct key distribution).

Scope: This PR successfully eliminates the N+1 query problem for the primary use case. No backwards-incompatible changes.

Confidence Score: 5/5

• This PR is safe to merge; it correctly eliminates N+1 queries with a well-tested batched approach and no backwards-incompatible changes.
• The logic is straightforward and correct: the batch query uses the existing @@index([team_id]) for efficient lookup, a list comprehension builds the batch, setdefault distributes keys, and the original team loop is otherwise untouched. The test covers the main invariant (single call + correct distribution). No files require special attention; both changed files are clean and correct.
• No files require special attention

Sequence Diagram

sequenceDiagram
    participant Client
    participant list_team
    participant DB as Database (Prisma)

    Client->>list_team: GET /team/list

    Note over list_team,DB: Before (N+1)
    list_team->>DB: get teams (find_many)
    DB-->>list_team: [team1, team2, ..., teamN]
    loop for each team
        list_team->>DB: find_many keys WHERE team_id = ?
        DB-->>list_team: keys for team
    end

    Note over list_team,DB: After (batched)
    list_team->>DB: get teams (find_many)
    DB-->>list_team: [team1, team2, ..., teamN]
    list_team->>DB: find_many keys WHERE team_id IN (id1, id2, ..., idN)
    DB-->>list_team: all keys (single query)
    list_team->>list_team: distribute keys in-memory by team_id

    list_team-->>Client: TeamListResponseObject[]

Loading

_{Last reviewed commit: 37a46e6}