feat: Unified Agent Auth - Dashboard UI

[khaliqgant]

Summary

Dashboard UI components for Unified Agent Auth system.

Phase 2:

• IntegrationConnect.tsx - Provider grid with 15 integrations, Nango OAuth flow
• IntegrationPolicyEditor.tsx - Policy editor with scope selection (read/write)

Phase 3:

• Audit log viewer page at /workspaces/[id]/audit
• Approval request UI with notification badge

Test Plan

• Provider grid displays all 15 integrations with correct categories
• Connect/disconnect flow works via Nango
• Policy editor allows scope selection per provider
• Audit log viewer shows paginated history
• Approval notifications appear for pending requests

Made with Cursor

---

[devin-ai-integration]

Devin Review found 2 potential issues.

View 6 additional findings in Devin Review.

[devin-ai-integration]

🔴 Stale closure: timeout never clears connecting state on connection timeout

The 5-minute timeout callback at line 202 compares connectingProvider === provider.id, but connectingProvider is captured from the closure at the time handleConnect was created. Since setConnectingProvider(provider.id) was called on line 131 (a state update that hasn't been reflected in the closure), the captured connectingProvider is the previous value (likely null). This means the condition connectingProvider === provider.id will always be false, so the timeout will never reset the connecting state or show the timeout error.

Root Cause: stale closure over React state in setTimeout

When handleConnect is invoked:

1. Line 131: setConnectingProvider(provider.id) — schedules a state update
2. Line 200-206: A setTimeout is created that captures connectingProvider from the current closure
3. The closure's connectingProvider is the value before the setConnectingProvider call (the old state), not provider.id

So when the timeout fires after 5 minutes:

if (connectingProvider === provider.id) { // always false
  setConnectingProvider(null);
  setError('Connection timed out');
}

The condition is always false. The interval is cleared (line 201), but the UI remains stuck in the "Connecting..." state forever, and no timeout error is shown to the user.

Impact: If the OAuth flow takes longer than 5 minutes or silently fails without returning an error status, the user sees an infinite "Connecting..." spinner with no way to recover except refreshing the page.

Suggested change

	setTimeout(() => {
	clearInterval(pollInterval);
	if (connectingProvider === provider.id) {
	setConnectingProvider(null);
	setError('Connection timed out');
	}
	}, 300000);
	setTimeout(() => {
	clearInterval(pollInterval);
	setConnectingProvider(prev => {
	if (prev === provider.id) {
	setError('Connection timed out');
	return null;
	}
	return prev;
	});
	}, 300000);

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔴 handleClearFilters fetches with old (stale) filter values instead of cleared filters

handleClearFilters calls setFilters(...) to clear filters and then immediately calls fetchEntries(true), but fetchEntries is a useCallback that closes over the current filters state. Since React state updates are asynchronous, fetchEntries still uses the old filter values.

Root Cause: stale closure over filters state

In handleClearFilters (line 142-147):

const handleClearFilters = () => {
  setFilters({ provider: '', agent: '', startTime: '', endTime: '' });
  setCursor(null);
  fetchEntries(true);  // uses OLD filters from closure
  setShowFilters(false);
};

fetchEntries is defined with useCallback(..., [workspaceId, filters, cursor]) at line 104-127. When handleClearFilters calls setFilters(...), the state update is batched and hasn't taken effect yet. The fetchEntries function still references the old filters object from its closure.

So when the user clicks "Clear" after setting filters (e.g., provider='github'), the API request is still made with provider=github instead of no filters. The user sees the filter panel close and expects unfiltered results, but gets the same filtered results.

Impact: The "Clear Filters" button doesn't actually clear filters on the current fetch — it fetches with the old filter values. The filters only take effect on the next fetch (e.g., if the user triggers another action).

Prompt for agents

In AuditLogViewer.tsx, the handleClearFilters function at line 142-147 calls setFilters() and then immediately calls fetchEntries(true), but fetchEntries closes over the stale filters state. To fix this, refactor fetchEntries to accept an optional filters parameter that overrides the state-based filters. For example, change the fetchEntries signature to accept (reset: boolean, overrideFilters?: AuditFilters), and when overrideFilters is provided, use those instead of the closed-over filters state. Then in handleClearFilters, pass the empty filters object directly: fetchEntries(true, { provider: '', agent: '', startTime: '', endTime: '' }). Apply the same pattern in handleApplyFilters if needed, passing the current filters explicitly.

---

Was this helpful? React with 👍 or 👎 to provide feedback.