refactor(chatCore): extrai recordKeyHealthStatus para leaf dedicado (#3501)

[diegosouzapw]

O quê

Próximo incremento da decomposição do god-file chatCore.ts (QG v2 Fase 9 T5, #3501). Extrai o closure recordKeyHealthStatus (~56 ln) do topo de handleChatCore para o novo leaf open-sse/handlers/chatCore/keyHealth.ts.

Stacked sobre o #4477 (leaf de service-tier). A base aponta para refactor/qg-chatcore-svctier; o GitHub re-aponta automaticamente para release/v3.8.32 quando o #4477 mergear.

Como (preservação de comportamento)

• Move byte-idêntico: 401 → recordKeyFailure + persist sempre; 2xx → recordKeySuccess + persist só na recuperação de warning/invalid; demais status apenas atualizam o set de extra-keys (trackConnectionExtraKeys).
• O handler mantém um closure fino de binding que repassa log, então os 2 call sites (dispatch a ~3063/3338) ficam inalterados.
• Imports que ficaram órfãos (recordKeyFailure / recordKeySuccess / trackConnectionExtraKeys / KeyHealth) migram para o leaf. connectionHasExtraKeys permanece no handler (ainda usado no site de rotação de chave); updateProviderConnection é importado em ambos (usado em vários pontos do handler).

Gates

• file-size: chatCore.ts 5110→5055 (shrink −55); baseline ratchetado.
• complexity: 1905 = baseline 1905 (neutro).
• typecheck:core: exit 0.
• Testes: tests/unit/chatcore-key-health.test.ts — 6 casos de caracterização das transições in-memory do apiKeyRotator (warning na 1ª falha, invalid no threshold=2, recuperação em 2xx, escopo por selectedKeyId, no-op sem connectionId e em status fora de 401/2xx). chatcore-imports-cleanly ✓ (sem imports órfãos) + 138/138 na suíte chatcore (excluído apenas o chatCore times out upstream execution, red flaky pré-existente comprovado no refactor(chatCore): extrai resolvers de service-tier do Codex para leaf puro (#3501) #4477).

Extração de god-file sem mudança de comportamento em runtime.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Code Review

This pull request refactors open-sse/handlers/chatCore.ts by extracting the recordKeyHealthStatus logic into a new dedicated module open-sse/handlers/chatCore/keyHealth.ts and introducing corresponding unit tests. The reviewer suggests mutating the in-memory creds.providerSpecificData object in-place before calling updateProviderConnection to ensure in-memory consistency and prevent stale health status reads during retries or subsequent executions within the same request lifecycle.

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]

The current implementation updates the database with the new apiKeyHealth but does not mutate the in-memory creds.providerSpecificData object in-place. This can lead to stale health status reads during retries or subsequent executions within the same request lifecycle if they share the same credentials reference. Mutating psd.apiKeyHealth in-place before calling updateProviderConnection ensures in-memory consistency.

    // Persist health status to DB on every failure (not just invalid transitions)
    // This ensures in-memory state survives process restarts
    const prevStatus = health?.[currentKeyId]?.status;
    const prevFailures = health?.[currentKeyId]?.failures ?? 0;
    if (updatedHealth.status !== prevStatus || updatedHealth.failures !== prevFailures) {
      if (psd) {
        if (!psd.apiKeyHealth) psd.apiKeyHealth = {};
        (psd.apiKeyHealth as Record<string, KeyHealth>)[currentKeyId] = updatedHealth;
      }
      updateProviderConnection(connId, {
        providerSpecificData: {
          ...psd,
        },
      }).catch((err: unknown) => {
        log?.error?.(
          "DB",
          `Failed to persist apiKeyHealth: ${err instanceof Error ? err.message : String(err)}`
        );
      });
    }
  } else if (status >= 200 && status < 300) {
    const updatedHealth = recordKeySuccess(connId, currentKeyId);
    const prevStatus = health?.[currentKeyId]?.status;
    if (prevStatus === "warning" || prevStatus === "invalid") {
      if (psd) {
        if (!psd.apiKeyHealth) psd.apiKeyHealth = {};
        (psd.apiKeyHealth as Record<string, KeyHealth>)[currentKeyId] = updatedHealth;
      }
      updateProviderConnection(connId, {
        providerSpecificData: {
          ...psd,
        },
      }).catch((err: unknown) => {
        log?.error?.(
          "DB",
          `Failed to persist apiKeyHealth: ${err instanceof Error ? err.message : String(err)}`
        );
      });
    }
  }