https://sonarly.com/issue/18288?type=bug
Users can create API keys without a name because `isDefined(canSave)` evaluates to `true` even when `canSave` is `false`. The resulting nameless API key renders as a blank page because the detail page conditionally renders only when `apiKey?.name` is truthy.
Fix: Two changes fix both the cause and the symptom:
**1. `SettingsDevelopersApiKeysNew.tsx` — Restore correct save button validation**
Changed `isSaveDisabled={!isDefined(canSave)}` back to `isSaveDisabled={!canSave}`. The `isDefined` wrapper was incorrectly added during the ESLint-to-OxLint migration (commit `9d57bc39e5d`). Since `canSave` is a boolean, `isDefined(false)` returns `true`, which meant the save button was always enabled. The original `!canSave` correctly disables save when the name is empty.
Also added `if (!formValues.name) return;` guard at the top of `handleSave()` as defense-in-depth, since the Enter key handler on the name input calls `handleSave()` directly without checking the `canSave` flag.
**2. `SettingsDevelopersApiKeyDetail.tsx` — Render page for nameless API keys**
Changed the render guard from `{apiKey?.name && (` to `{isDefined(apiKey) && (`. The old guard treated an empty-string name as falsy, hiding the entire page content. The new guard correctly checks for data presence. The title and breadcrumb now fall back to a translated `"Unnamed API Key"` label when the name is empty, keeping the page usable so users can either rename or delete the broken API key.
Sonarly Claude Code
136daecbf5