fix(resilience): expose providerCooldown in GET+PATCH /api/resilience

[diegosouzapw]

Problem

Settings → Resilience page crashes on load. The ResilienceTab component fetches GET /api/resilience and expects a providerCooldown field to render the Provider Cooldown card added in #3556. The route did not return it — providerCooldown was wired into the settings model and UI but never exposed in the API.

Root cause

Three omissions in src/app/api/resilience/route.ts:

1. GET response missing providerCooldown → component received undefined, crashed rendering the card
2. PATCH handler not merging body.providerCooldown into nextResilience → saves were silently dropped
3. PATCH response missing providerCooldown → component state desync after save

And one in src/shared/validation/schemas.ts:
4. updateResilienceSchema used .strict() → rejected PATCH bodies containing providerCooldown with 400

Fix

• Add providerCooldownSettingsSchema (enabled, minRetryCooldownMs, maxRetryCooldownMs with bounds)
• Add providerCooldown to updateResilienceSchema + superRefine empty-body guard
• Expose providerCooldown in GET response
• Merge body.providerCooldown in PATCH handler
• Return providerCooldown in PATCH response

Tests

5 new unit tests (TDD — all were red before fix, green after):

• Schema accepts valid/partial providerCooldown patch
• Schema rejects unknown keys inside providerCooldown
• mergeResilienceSettings merges overrides correctly
• resolveResilienceSettings returns providerCooldown field

node --import tsx/esm --test --test-force-exit tests/unit/resilience-provider-cooldown-api-3556.test.ts
# ℹ pass 5  ℹ fail 0

Fixes the Settings → Resilience page crash introduced by #3556.

[gemini-code-assist]

Code Review

This pull request adds support for the providerCooldown configuration in the GET and PATCH endpoints of /api/resilience, updates the validation schema, and includes regression tests. The reviewer pointed out a discrepancy between the maximum limits enforced by the new Zod schema and the backend normalization logic for minRetryCooldownMs and maxRetryCooldownMs, and suggested aligning them and adding a refinement to ensure minRetryCooldownMs is less than or equal to maxRetryCooldownMs.

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]

There is a discrepancy between the maximum limits enforced by this Zod schema and those allowed by the backend normalization logic in src/lib/resilience/settings.ts:

• minRetryCooldownMs: Schema max is 300000 (5 minutes), but the backend allows up to 3600000 (1 hour).
• maxRetryCooldownMs: Schema max is 3600000 (1 hour), but the backend allows up to 86400000 (24 hours).

This discrepancy will cause the API to reject valid configurations that the backend is fully capable of supporting. We should align the schema limits with the backend's normalization limits.

Additionally, we can add a refinement to ensure minRetryCooldownMs is less than or equal to maxRetryCooldownMs when both are provided.

const providerCooldownSettingsSchema = z
  .object({
    enabled: z.boolean().optional(),
    minRetryCooldownMs: z.number().int().min(0).max(3600000).optional(),
    maxRetryCooldownMs: z.number().int().min(0).max(86400000).optional(),
  })
  .strict()
  .superRefine((value, ctx) => {
    if (
      typeof value.minRetryCooldownMs === "number" &&
      typeof value.maxRetryCooldownMs === "number" &&
      value.minRetryCooldownMs > value.maxRetryCooldownMs
    ) {
      ctx.addIssue({
        code: z.ZodIssueCode.custom,
        message: "minRetryCooldownMs must be less than or equal to maxRetryCooldownMs",
        path: ["maxRetryCooldownMs"],
      });
    }
  });