feat(dashboard): add search and filters to /dashboard/api-manager

[diegosouzapw]

Summary

Implements task _tasks/features-v3.8.3/refactorpages/01-api-manager-search-and-filters.plan.md (Layout B — Híbrido: Stats + Filter Card).

• Adds a search bar (matches name or key substring, case-insensitive) and an "Active only" toggle (persisted in localStorage) above the keys table.
• Adds two mutually-exclusive chip groups with live counts:
  • STATUS: All / Active / Disabled / Banned / Expired
  • TYPE: All / Standard / Manage / Restricted
• STATUS and TYPE share one row on screens ≥1280px (vertical divider between them); wrap to two rows on smaller widths.
• Card title shows (X of Y shown) when any filter/search is active; otherwise (N).
• Empty state with a "Clear filters" button when filters yield zero results.
• Pure helpers (isKeyActive, isExpired, isRestricted, classifyKeyStatus, classifyKeyType, computeApiKeyCounts) extracted to apiManagerPageUtils.ts.

Files

New:

• src/app/(dashboard)/dashboard/api-manager/apiManagerPageStorage.ts
• src/app/(dashboard)/dashboard/api-manager/apiManagerPageUtils.ts
• src/app/(dashboard)/dashboard/api-manager/components/ApiKeyFilterBar.tsx
• src/app/(dashboard)/dashboard/api-manager/components/ApiKeyFilterChip.tsx
• tests/unit/api-manager-filters.test.ts

Modified:

• src/app/(dashboard)/dashboard/api-manager/ApiManagerPageClient.tsx (+105 lines)
• src/i18n/messages/en.json (+15 keys under apiManager)
• src/i18n/messages/pt-BR.json (+15 keys, translated)

Validations

• npm run typecheck:core → clean
• npm run lint → 0 errors (only pre-existing warnings)
• node --import tsx/esm --test tests/unit/api-manager-filters.test.ts → 38/38 pass

Test plan

• Open /dashboard/api-manager with several keys (mix of active / disabled / banned / expired / manage / restricted)
• Search updates the list in real time and the title becomes (X of Y shown)
• Toggle "Active only" filters and persists after reload
• Each STATUS chip filters mutually-exclusively and counts are correct
• Each TYPE chip filters mutually-exclusively and counts are correct
• Enabling "Active only" with another status chip active resets the chip
• Clicking a non-Active status chip with toggle on disables the toggle
• STATUS + TYPE render on one row at viewport ≥1280px, two rows below
• Empty state appears when filters yield zero results; "Clear filters" resets everything
• Create / edit / delete / copy key flows still work

[chatgpt-codex-connector]

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

[kilo-code-bot]

Kilo Code Review could not run — your account is out of credits.

Add credits or switch to a free model to enable reviews on this change.

[gemini-code-assist]

Code Review

This pull request introduces a comprehensive filtering and search system for the API Manager, including new utility functions, storage helpers, and UI components. Feedback identifies a race condition in the persistence logic for the active-only toggle and logic inconsistencies between classification helpers and the filtering implementation. Recommendations were also provided to improve performance via debouncing and memoization, refactor utilities for better logic reuse, and ensure UI consistency and safety.

[gemini-code-assist]

The current persistence logic for activeOnly has a race condition. On the initial render, activeOnly is false. The second useEffect (line 151) will trigger and write false to localStorage before the first useEffect (line 147) can read the saved value and update the state. This effectively overwrites the user's preference with the default value on every page load.

Consider using a ref to skip the initial write or initializing the state from localStorage using a lazy initializer (though the latter requires careful handling of hydration in Next.js).

[gemini-code-assist]

The filtering logic for statusFilter and typeFilter is inconsistent with the classification logic used to compute chip counts in computeApiKeyCounts.

For example, if a key is both banned and isActive: false, classifyKeyStatus (used for counts) returns "banned". However, the filter for "disabled" (line 277) will still include this key because it only checks isActive === false. This results in a mismatch where a chip might show a count of 0 but clicking it displays results.

To ensure consistency, use the classification helpers directly in the filter logic.

Suggested change

	// 2. status chip filter
	if (statusFilter === "active") list = list.filter(isKeyActive);
	else if (statusFilter === "disabled") list = list.filter((k) => k.isActive === false);
	else if (statusFilter === "banned") list = list.filter((k) => k.isBanned === true);
	else if (statusFilter === "expired") list = list.filter(isExpired);
	// 3. type chip filter
	if (typeFilter === "manage") list = list.filter((k) => k.scopes?.includes("manage"));
	else if (typeFilter === "restricted") list = list.filter(isKeyRestricted);
	else if (typeFilter === "standard")
	list = list.filter((k) => !k.scopes?.includes("manage") && !isKeyRestricted(k));
	// 2. status chip filter
	if (statusFilter) {
	list = list.filter((k) => classifyKeyStatus(k) === statusFilter);
	}
	// 3. type chip filter
	if (typeFilter) {
	list = list.filter((k) => classifyKeyType(k) === typeFilter);
	}

[gemini-code-assist]

The search filter is performed on every keystroke within a useMemo block. For large lists of API keys, this can lead to UI lag.

Consider using the existing useDebouncedValue hook to debounce the searchQuery before applying it to the filteredKeys computation.

[gemini-code-assist]

These local variables duplicate logic now available in the isRestricted utility. Additionally, the isRestricted icon logic at line 741 only checks for model restrictions, ignoring connection restrictions, which is inconsistent with the new filter definitions.

Suggested change

	const isRestricted = Array.isArray(key.allowedModels) && key.allowedModels.length > 0;
	const hasConnectionRestrictions =
	const isRestricted = isKeyRestricted(key);
	const hasModelRestrictions = Array.isArray(key.allowedModels) && key.allowedModels.length > 0;
	const hasConnectionRestrictions = Array.isArray(key.allowedConnections) && key.allowedConnections.length > 0;

[gemini-code-assist]

The isKeyActive function manually checks expiration logic which is already encapsulated in isExpired. Furthermore, isKeyActive lacks the NaN check for date parsing that isExpired includes.

Refactor to reuse isExpired for consistency and safety.

export function isKeyActive(k: ApiKeyShape): boolean {
  if (k.isBanned === true) return false;
  if (k.isActive === false) return false;
  if (isExpired(k)) return false;
  return true;
}

[gemini-code-assist]

The statusChips and typeChips arrays are recreated on every render of ApiKeyFilterBar. Since their structure is static (only the count property changes), they should be memoized or the static parts moved outside the component to avoid unnecessary allocations.

[gemini-code-assist]

Buttons should explicitly define their type to prevent accidental form submissions if the component is ever nested within a <form> element.

    <button
      type="button"
      onClick={onClick}

[github-actions]

CI Coverage Report

• Coverage job: skipped
• PR test policy: success

Coverage artifact was not available for this run.