fix(proxy): resolve registry assignments for combo and key levels

[terence71-glitch]

Summary

GET /api/settings/proxy?level=...&id=... previously consulted the proxy
registry only for global and provider levels. Requests for combo and
key fell straight through to the legacy getProxyForLevel() path, so a
proxy assigned through the registry UI was invisible to per-level reads at
those two levels — the response showed the old proxyConfig.combos /
proxyConfig.keys value (or null) instead of the registry assignment.

This PR routes all four levels through a single registry-lookup helper, with
the legacy store kept as a fallback when no registry assignment exists.

Changes

src/app/api/settings/proxy/route.ts

• New PROXY_LEVEL_TO_REGISTRY_SCOPE map translating the route's public
  level names to the canonical ProxyScope used by src/lib/db/proxies.ts:

  global   -> global
  provider -> provider
  combo    -> combo
  key      -> account
  

  The key -> account entry mirrors normalizeScope() in proxies.ts:157,
  where account is the canonical internal scope and key is the legacy
  public-API alias.
• New helpers:
  • getRegistryScopeForLevel(level) — typed map lookup.
  • getRegistryProxyForLevel(level, id) — fetches the assignment for the
    scope, returns the underlying proxy_registry row (with secrets), or
    null when there is no assignment or the level is unknown.
  • toProxyConfig(proxyData) — extracts { type, host, port, username, password } from a registry row. Previously inlined twice.
• GET handler collapses the four per-level branches into one:

  if (level) {
    const proxyData = await getRegistryProxyForLevel(level, id);
    if (proxyData) {
      return Response.json({
        level,
        id: level === "global" ? null : id,
        proxy: toProxyConfig(proxyData),
      });
    }
    const proxy = await getProxyForLevel(level, id);
    return Response.json({ level, id, proxy });
  }

• Full-config GET path also uses toProxyConfig() for the provider loop,
  removing the last inline duplicate.

tests/unit/route-edge-coverage.test.ts

• New test
  settings proxy route resolves combo and key registry assignments with legacy fallback:
  1. PUTs legacy combos.comboA and keys.accountA proxies — asserts both
     GETs return the legacy values (legacy fallback path).
  2. Creates two proxies via localDb.createProxy, assigns one to
     (combo, comboA) and one to (account, accountA) via
     assignProxyToScope.
  3. Re-issues both per-level GETs — asserts they now return the registry
     proxy hostnames, usernames, and decrypted passwords (registry path).

Behavior contract preserved

• global: registry uses assignments[0] (there is only ever one row,
  keyed by __global__); response forces id: null.
• Non-global levels: assignment.scopeId === id match. mapAssignmentRow
  only strips __global__ for the global scope, so combo and account
  scopeIds round-trip unchanged.
• Registry-first, legacy-fallback ordering is unchanged.
• No change to PUT or DELETE handlers.

Naming note

The route accepts only key (not account) as the level name on the
public surface. This matches the docstring, the legacy proxyConfig.keys
map, and the PUT body's keys field. If a caller passes
?level=account, the level is unknown to the route, the registry helper
returns null, and the request falls through to legacy
getProxyForLevel("account", ...). This is intentional — keeping the
public-vs-internal naming boundary intact.

Test plan

• node --import tsx/esm --test tests/unit/route-edge-coverage.test.ts
  — new test passes; existing prefers proxy registry assignments…
  test still passes (no regression on global/provider paths).
• npm run typecheck:core — clean.
• npm run lint — 0 errors.

[gemini-code-assist]

Code Review

This pull request refactors the proxy settings API route to consolidate and simplify proxy assignment retrieval across different levels (global, provider, combo, and key) using helper functions, and adds corresponding unit tests for combo and key registry assignments. Feedback was provided to address a potential prototype lookup vulnerability in the getRegistryScopeForLevel function by safely checking if the key exists on the mapping object before performing the lookup.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Using a direct lookup on PROXY_LEVEL_TO_REGISTRY_SCOPE with level as keyof typeof PROXY_LEVEL_TO_REGISTRY_SCOPE can lead to prototype lookup issues if level matches built-in object properties (e.g., "toString", "constructor", "valueOf"). If a client passes ?level=toString, the lookup will return a function instead of undefined, which could cause runtime errors or unexpected behavior when passed to downstream database queries.

To prevent this, safely check if the key exists on the object using Object.prototype.hasOwnProperty.call before performing the lookup.

function getRegistryScopeForLevel(level: string): "global" | "provider" | "combo" | "account" | undefined {
  if (Object.prototype.hasOwnProperty.call(PROXY_LEVEL_TO_REGISTRY_SCOPE, level)) {
    return PROXY_LEVEL_TO_REGISTRY_SCOPE[
      level as keyof typeof PROXY_LEVEL_TO_REGISTRY_SCOPE
    ];
  }
  return undefined;
}

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

The PR refactors the proxy settings route to use the proxy registry for combo and key level proxy resolution, with proper legacy fallback. The changes are well-structured and maintain backward compatibility.

Files Reviewed (2 files)

• src/app/api/settings/proxy/route.ts — 35 lines added, 44 lines removed (refactored with helper functions)
• tests/unit/route-edge-coverage.test.ts — 75 lines added (test coverage for combo/key registry assignments)

Overview

Changes:

• Added PROXY_LEVEL_TO_REGISTRY_SCOPE mapping to normalize API level names to registry scope names (key → account)
• Created getRegistryScopeForLevel() and getRegistryProxyForLevel() helper functions
• Created toProxyConfig() helper to avoid repetitive proxy config object construction
• Refactored GET handler to consolidate redundant conditional blocks into a single flow
• Added test covering registry proxy resolution for combo and key levels with legacy fallback

Security & Error Handling:

• All routes use requireManagementAuth for authentication
• Input validation handled by Zod schema (updateProxyConfigSchema)
• Legacy fallback gracefully handles missing registry entries
• Type safety preserved with proper nullable checks

Test Coverage:

• New test "settings proxy route resolves combo and key registry assignments with legacy fallback" validates both legacy and registry proxy resolution paths
• Tests verify proxy host, username, and password are correctly returned from registry
• Edge cases covered for missing id, invalid levels, etc.

---

_{Reviewed by laguna-m.1-20260312:free · 2,823,953 tokens}

[terence71-glitch]

getRegistryScopeForLevel() now verifies the requested level with Object.prototype.hasOwnProperty.call(...) before indexing PROXY_LEVEL_TO_REGISTRY_SCOPE, so inherited object properties like toString/constructor cannot be treated as valid registry scopes.

Validation rerun:

• npx eslint src/app/api/settings/proxy/route.ts tests/unit/route-edge-coverage.test.ts
• npx cross-env DISABLE_SQLITE_AUTO_BACKUP=true node --import tsx --test --test-force-exit tests/unit/route-edge-coverage.test.ts

Result: 16 pass, 0 fail.