AI & Agent Dev Bug Sandbox Back to Radar

Validate BackendProviders Against Supported Providers

The registry schema accepts arbitrary strings for `backendProviders`, allowing unsupported provider names to bypass validation. This can cause runtime errors or silent misconfiguration. The proposed change restricts values to the known supported providers using a Zod enum.

mediumConfidence 88%Zod

Origin Analysis

The schema definition uses `z.array(z.string()).optional()` for `backendProviders`, which lacks validation against the list of supported providers (`next-auth`, `supabase`, `auth0`). The existing `isBackendProvider` type guard is not enforced in the schema.

1. Locate the registry schema definition. 2. Provide a configuration with `backendProviders: ['unsupported-provider']`. 3. Observe that schema validation passes despite the unsupported value. 4. The application may later fail or behave unexpectedly when attempting to use the invalid provider.

Fixing Code Block

const backendProviderValues = ['next-auth', 'supabase', 'auth0'] as const;

backendProviders: z.array(z.enum(backendProviderValues)).optional(),
// Remove the unused isBackendProvider function if no other references exist.

Replace `z.array(z.string())` with `z.array(z.enum(backendProviderValues))` to restrict accepted values to the known supported backend providers. This catches typos and invalid configurations early. The `as const` assertion preserves literal types for the enum. The unused `isBackendProvider` function can be safely removed.

Edge Case Audit

This change may break existing configurations that include arbitrary strings in `backendProviders`. Before rolling out, scan current configs for unsupported values and either migrate or provide a fallback. If new providers are added later, the hardcoded array must be updated, otherwise valid new providers will be rejected. To roll back, revert the schema change and restore the previous validation logic.