feat(dashboard): add GraphQL provider for dashboard data

[seanhanca]

Summary

Changes

Type

• Feature
• Bug fix
• Refactor
• Documentation
• CI / Tooling
• Plugin (new or update)
• Dependencies

Plugin(s) Affected

Checklist

• Tests pass locally
• Lint passes (npm run lint)
• Build succeeds (npm run build)
• No new lint warnings introduced
• Breaking changes documented below
• Database migration included (if Prisma schema changed)

Breaking Changes

None

Screenshots / Recordings

Summary by CodeRabbit

• New Features

  • Added customizable polling interval selector to dashboard with persistent user preference.
  • Added network online status indicator to dashboard header.

• Bug Fixes

  • Improved plugin installation detection logic for accurate state tracking.
  • Plugin installation events now only fire on successful installs.
  • Enhanced error recovery in capacity planner with granular optimistic rollback instead of full data reload.
  • Improved plugin data refresh when plugins are installed or uninstalled.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
naap-platform	Ready	Preview, Comment	Feb 10, 2026 10:01pm

[github-actions]

⚠️ This PR is large (210 lines changed). Consider splitting it into smaller PRs for easier review.

[vercel]

Additional Suggestion:

handleInstall function fails silently when plugin installation fails - no error notification is shown to the user

[vercel]

DELETE endpoints silently ignore all errors when deleting user plugin preferences, causing them to return success even when deletion fails, leaving inconsistent database state

[vercel]

Plugin filter in settings page incorrectly includes plugins with undefined installed field, not just explicitly installed or core plugins

[seanhanca]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Caution

Review failed

The pull request is closed.

📝 Walkthrough

Walkthrough

The changes introduce dynamic polling interval selection in the dashboard with localStorage persistence, refine plugin installation detection and event emission across marketplace and settings pages, extend plugin event handling in the sidebar to refresh on install/uninstall, adjust capacity-planner API response shapes, and implement optimistic-rollback error handling in the capacity-planner frontend.

Changes

Cohort / File(s)	Summary
Dashboard Polling Control apps/web-next/src/app/(dashboard)/dashboard/page.tsx	Added client-side polling interval support with localStorage persistence, PollIntervalSelector component, poll state management, and wired DashboardHeader to accept and render poll interval controls.
Plugin Installation & Event System apps/web-next/src/app/(dashboard)/marketplace/page.tsx, apps/web-next/src/app/(dashboard)/settings/page.tsx, apps/web-next/src/components/layout/sidebar.tsx	Reworked installed plugin detection logic to filter by installed/enabled flags; added plugin:installed and plugin:uninstalled event emission on successful operations; extended sidebar to listen for and handle plugin lifecycle events to trigger refreshPlugins().
Capacity Planner Backend Response Shape plugins/capacity-planner/backend/src/server.ts	Updated commit endpoint API responses to wrap action inside data object for consistency across success paths.
Capacity Planner Frontend Error Handling plugins/capacity-planner/frontend/src/pages/Capacity.tsx	Replaced full data reload on toggle commit failure with granular optimistic-rollback flow; reverts affected capacity request state and committedIds on error; adjusted handleThumbsUp dependency array to exclude loadRequests.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant Capacity as Capacity.tsx<br/>(Component)
    participant API as Backend API
    participant State as Local State<br/>(committedIds)

    User->>Capacity: Click thumbs up on request
    Note over Capacity: Optimistic: add to committedIds
    Capacity->>Capacity: Update UI with committed state
    Capacity->>API: Toggle commit request
    
    alt Success
        API-->>Capacity: { success: true }
        Note over State: committedIds confirmed
    else Failure
        API-->>Capacity: Error response
        Capacity->>Capacity: Check prior state (alreadyCommitted)
        Capacity->>State: Revert committedIds for request
        Note over Capacity: Rollback optimistic update<br/>re-add/remove soft entry
        Capacity->>Capacity: Update selected view if open
    end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 1 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The title 'feat(dashboard): add GraphQL provider for dashboard data' does not match the actual changes. The PR primarily implements polling intervals, plugin installation/uninstallment handling, and various fixes across multiple areas, with no evidence of GraphQL provider implementation.	Update the title to accurately reflect the main changes, such as 'feat(dashboard): add polling interval selector and plugin lifecycle improvements' or a more specific summary of the actual implementation.
Docstring Coverage	⚠️ Warning	Docstring coverage is 42.86% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/dashboard-graphql-provider

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 4

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (5)

packages/plugin-sdk/src/integrations/email/sendgrid.ts (2)

117-119: ⚠️ Potential issue | 🟠 Major

Type mismatch: sendTemplate was not updated to use convertOptions.

options?.from and options?.replyTo are EmailRecipient objects (per EmailOptions interface), not strings. This causes incorrect payload structure—{ email: options.from } would nest an object where a string is expected. Additionally, cc and bcc are not handled here unlike in send/sendHtml.

Proposed fix to use convertOptions consistently

   async sendTemplate(
     to: string | string[],
     templateId: string,
     variables: Record<string, unknown>,
     options?: EmailOptions
   ): Promise<void> {
     const toArray = Array.isArray(to) ? to : [to];
+    const converted = this.convertOptions(options);
     
     const response = await this.request('POST', '/mail/send', {
       personalizations: [{
         to: toArray.map(email => ({ email })),
         dynamic_template_data: variables,
+        cc: converted.cc?.map(email => ({ email })),
+        bcc: converted.bcc?.map(email => ({ email })),
       }],
-      from: { email: options?.from || this.fromEmail || 'noreply@example.com' },
+      from: { email: converted.from || this.fromEmail || 'noreply@example.com' },
       template_id: templateId,
-      reply_to: options?.replyTo ? { email: options.replyTo } : undefined,
+      reply_to: converted.replyTo ? { email: converted.replyTo } : undefined,
     });

     if (!response.ok) {
       const error = await response.json().catch(() => ({}));
       throw new Error(error.errors?.[0]?.message || `SendGrid error: ${response.status}`);
     }
   }

---

169-173: ⚠️ Potential issue | 🟠 Major

Missing await on async initialize call.

initialize is async but the call isn't awaited. The returned integration won't have its API key set, causing subsequent API calls to fail. Consider making the factory async or documenting that callers must await initialize separately.

Option 1: Make factory async

-export function createSendGridIntegration(config: IntegrationConfig): SendGridIntegration {
+export async function createSendGridIntegration(config: IntegrationConfig): Promise<SendGridIntegration> {
   const integration = new SendGridIntegration();
-  integration.initialize(config);
+  await integration.initialize(config);
   return integration;
 }

packages/plugin-sdk/cli/commands/github.ts (1)

304-358: ⚠️ Potential issue | 🟠 Major

backend-only plugin type not handled by generateWorkflow.

The select prompt (lines 54-61) offers 'backend-only' as a valid option, but generateWorkflow only checks for 'frontend-only' and falls through to the full-stack workflow for all other types. This means backend-only plugins get a workflow that includes frontend build steps (lines 394-405), which would fail in CI since frontend/ doesn't exist.

🐛 Proposed fix to handle backend-only case

 function generateWorkflow(type: string, manifest: { name: string; version: string }): string {
   const baseWorkflow = `# NAAP Plugin Publishing Workflow
 ...
 `;

   if (type === 'frontend-only') {
     return baseWorkflow + `jobs:
 ...
 `;
   }

+  if (type === 'backend-only') {
+    // Generate workflow without frontend build steps
+    return baseWorkflow + `jobs:
+  build:
+    name: Build & Test
+    runs-on: ubuntu-latest
+    outputs:
+      version: \${{ steps.version.outputs.version }}
+    
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: \${{ env.NODE_VERSION }}
+          cache: 'npm'
+
+      - name: Get version
+        id: version
+        run: |
+          if [ "\${{ github.event_name }}" = "release" ]; then
+            VERSION="\${{ github.event.release.tag_name }}"
+            VERSION="\${VERSION#v}"
+          else
+            VERSION="\${{ github.event.inputs.version }}"
+          fi
+          echo "version=$VERSION" >> $GITHUB_OUTPUT
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Run tests
+        if: \${{ github.event.inputs.skip_tests != 'true' }}
+        run: npm test --if-present
+
+  docker:
+    name: Build Docker Image
+    needs: build
+    # ... (Docker build steps similar to full-stack)
+
+  publish:
+    name: Publish to Registry
+    needs: [build, docker]
+    # ... (Publish steps without frontend artifact download)
+`;
+  }
+
   // Full-stack workflow
   return baseWorkflow + `jobs:
 ...

plugins/capacity-planner/backend/src/server.ts (1)

360-372: ⚠️ Potential issue | 🟠 Major

Align commit-toggle response schema across DB and fallback paths

At Line 364 and Line 371 the Prisma branch now returns data: { action }, but the in-memory fallback still returns { data: r, action }. This yields two different response shapes depending on DB availability, which can break clients or tests when the fallback path is used. Please pick a single contract (e.g., data: { action } or data: { action, request }) and apply it consistently across both branches.

apps/web-next/package.json (1)

62-71: ⚠️ Potential issue | 🟠 Major

Update @vitejs/plugin-react to v5.x for Vitest 4 compatibility.

The project currently uses @vitejs/plugin-react@^4.3.0, which is incompatible with Vite 6+. Vitest 4.0.18 requires Vite ^6.0.0 || ^7.0.0, but the older plugin-react version does not support these Vite versions. This mismatch is already flagged by the @ts-expect-error comment on line 6 of apps/web-next/vitest.config.ts.

Upgrade @vitejs/plugin-react to ^5.x (e.g., 5.1.4), which supports Vite 6/7. Node version compatibility is fine (project targets Node 22+, which is within Vitest 4's supported range). The vitest config itself requires minimal changes—the coverage provider is already set to 'v8' and does not use removed options.

🤖 Fix all issues with AI agents

In `@apps/web-next/src/app/api/v1/base/plugins/preferences/route.ts`:
- Line 16: CORE_PLUGINS is checked with case-sensitive matching which allows
bypasses; normalize the incoming plugin name the same way as in
personalized/route.ts (use name.toLowerCase().replace(/[-_]/g, '')) before any
CORE_PLUGINS.includes(...) checks. Update the check in preferences/route.ts
(where CORE_PLUGINS is referenced) and also mirror the same normalization in
installations/[name]/route.ts so both the uninstall/install protection use the
normalized pluginName when calling CORE_PLUGINS.includes(pluginName).

In `@packages/plugin-sdk/cli/commands/dev.ts`:
- Around line 52-53: Replace the explicit any for the tracked child process type
on the processes array with execa v8's ResultPromise: change the variable
declaration for processes (currently const processes: { name: string; process:
any }[] = []) to use ResultPromise for the process field, and add an import type
{ ResultPromise } from 'execa'; so the shape becomes { name: string; process:
ResultPromise }[]; this aligns the type with how the code uses the items
(awaiting with Promise.all, reading .stdout/.stderr and calling .kill()) and
removes the eslint no-explicit-any usage.

In `@packages/plugin-sdk/src/integrations/email/sendgrid.ts`:
- Around line 87-102: The convertOptions method currently drops
EmailOptions.attachments silently; update the implementation so attachments are
not ignored: either map options.attachments into SendGrid-compatible attachment
objects and include them in the payload sent by sendMail (add handling in
sendMail and propagate from convertOptions), or detect options.attachments in
convertOptions/sendMail and emit a clear warning or throw an error when
attachments are present (use the existing logger or throw to make it explicit).
Refer to the EmailOptions type and the convertOptions and sendMail functions
when adding this detection/translation so callers no longer lose attachments
silently.

In `@plugins/capacity-planner/frontend/src/pages/Capacity.tsx`:
- Around line 215-236: The rollback in the API error handler is using
setSelectedRequest with a closure that can mutate the wrong selection if the
user switched requests; inside the setter (the function passed to
setSelectedRequest) check that prev?.id === request.id before applying the
softCommits addition/removal logic (using selectedRequest, request.id,
alreadyCommitted, user.id for context) and if the IDs differ simply return prev
to avoid mutating a stale selection.

🧹 Nitpick comments (6)

apps/web-next/src/lib/plugins/__tests__/integration.test.ts (1)

143-153: Tighten the strict‑mode token assertion to avoid false positives.

Line 152 currently allows any falsy value; if the contract is specifically '' or null, assert those explicitly so regressions (e.g., false) don’t slip through.

Suggested change

-    expect(token).toBeFalsy(); // Returns '' or null in strict mode
+    expect(token === '' || token === null).toBe(true); // Returns '' or null in strict mode

packages/plugin-sdk/cli/commands/package.ts (1)

162-164: Consider backward compatibility for the renamed skip flag.

Switching the guard to skipBundleValidation means existing scripts passing --skip-mf-validation will no longer skip validation (and may fail). If compatibility matters, consider accepting the old flag as a deprecated alias or documenting the breaking change.

♻️ Example compatibility shim

-      if (manifest.frontend && !options.skipBundleValidation) {
+      const skipBundleValidation =
+        options.skipBundleValidation ?? (options as any).skipMfValidation;
+      if (manifest.frontend && !skipBundleValidation) {

If you go this route, also expose the deprecated flag in the command options/type so it parses.

apps/web-next/src/hooks/__tests__/useJobFeedStream.test.ts (1)

143-164: Make fake-timer cleanup unconditional.
If an assertion throws early, timers can stay faked and bleed into later tests. Wrap with try/finally or move vi.useRealTimers() into afterEach.

♻️ Example using try/finally

  it('returns error when no provider registered', async () => {
    vi.useFakeTimers();
-    const noHandlerError = new Error('No handler');
-    (noHandlerError as any).code = 'NO_HANDLER';
-    // Reject all retry attempts (initial + 4 retries)
-    mockEventBus.request.mockRejectedValue(noHandlerError);
-
-    const { result } = renderHook(() => useJobFeedStream());
-
-    // Flush all retry timers (1000, 2000, 3000, 5000ms)
-    for (let i = 0; i < 5; i++) {
-      await act(async () => {
-        vi.advanceTimersByTime(5000);
-      });
-    }
-
-    expect(result.current.error).not.toBeNull();
-    expect(result.current.error!.type).toBe('no-provider');
-    expect(result.current.connected).toBe(false);
-
-    vi.useRealTimers();
+    try {
+      const noHandlerError = new Error('No handler');
+      (noHandlerError as any).code = 'NO_HANDLER';
+      // Reject all retry attempts (initial + 4 retries)
+      mockEventBus.request.mockRejectedValue(noHandlerError);
+
+      const { result } = renderHook(() => useJobFeedStream());
+
+      // Flush all retry timers (1000, 2000, 3000, 5000ms)
+      for (let i = 0; i < 5; i++) {
+        await act(async () => {
+          vi.advanceTimersByTime(5000);
+        });
+      }
+
+      expect(result.current.error).not.toBeNull();
+      expect(result.current.error!.type).toBe('no-provider');
+      expect(result.current.connected).toBe(false);
+    } finally {
+      vi.useRealTimers();
+    }
  });

```

apps/web-next/src/hooks/__tests__/useDashboardQuery.test.ts (1)

76-97: Ensure fake timers are always restored.
If the test fails early, fake timers can leak to other tests. Prefer try/finally or a shared afterEach.

♻️ Example using try/finally

  it('returns error with type=no-provider when no handler registered', async () => {
    vi.useFakeTimers();
-    const noHandlerError = new Error('No handler registered for event: dashboard:query');
-    (noHandlerError as any).code = 'NO_HANDLER';
-    // Reject all retry attempts (initial + 4 retries)
-    mockEventBus.request.mockRejectedValue(noHandlerError);
-
-    const { result } = renderHook(() => useDashboardQuery(testQuery));
-
-    // Flush all retry timers (1000, 2000, 3000, 5000ms)
-    for (let i = 0; i < 5; i++) {
-      await act(async () => {
-        vi.advanceTimersByTime(5000);
-      });
-    }
-
-    expect(result.current.error).toBeDefined();
-    expect(result.current.error!.type).toBe('no-provider');
-    expect(result.current.data).toBeNull();
-
-    vi.useRealTimers();
+    try {
+      const noHandlerError = new Error('No handler registered for event: dashboard:query');
+      (noHandlerError as any).code = 'NO_HANDLER';
+      // Reject all retry attempts (initial + 4 retries)
+      mockEventBus.request.mockRejectedValue(noHandlerError);
+
+      const { result } = renderHook(() => useDashboardQuery(testQuery));
+
+      // Flush all retry timers (1000, 2000, 3000, 5000ms)
+      for (let i = 0; i < 5; i++) {
+        await act(async () => {
+          vi.advanceTimersByTime(5000);
+        });
+      }
+
+      expect(result.current.error).toBeDefined();
+      expect(result.current.error!.type).toBe('no-provider');
+      expect(result.current.data).toBeNull();
+    } finally {
+      vi.useRealTimers();
+    }
  });

```

apps/web-next/src/app/api/v1/base/plugins/personalized/route.ts (1)

191-208: Consider extracting CORE_PLUGIN_NAMES and normalization helpers to module scope.

The CORE_PLUGIN_NAMES array and normalization functions are defined multiple times within this file (lines 96, 163, 173, 192, 220). Additionally, the personal context list includes 'my-wallet' and 'my-dashboard' which are not present in the team context lists. This inconsistency could lead to subtle bugs where a plugin is considered core in one context but not another.

♻️ Suggested refactor

+// Module-level constants
+const CORE_PLUGIN_NAMES = ['marketplace', 'plugin-publisher', 'pluginpublisher', 'my-wallet', 'my-dashboard'];
+const normalizePluginName = (name: string) => name.toLowerCase().replace(/[-_]/g, '');
+
 export async function GET(request: NextRequest): Promise<NextResponse> {
   try {
     // ... existing code ...
-    // Core plugin names that are always considered "installed"
-    const CORE_PLUGIN_NAMES = ['marketplace', 'plugin-publisher', 'pluginpublisher', 'my-wallet', 'my-dashboard'];
-    const normalizeForCore = (name: string) => name.toLowerCase().replace(/[-_]/g, '');
+    const isCore = CORE_PLUGIN_NAMES.includes(normalizePluginName(plugin.name));

apps/web-next/src/app/(dashboard)/marketplace/page.tsx (1)

568-591: Consider extracting the duplicated filter predicate.

The same filter logic appears twice (lines 573-574 and 582-584). Extracting it would improve maintainability.

♻️ Suggested refactor

+        const isPluginInstalled = (p: { installed?: boolean; enabled?: boolean }) =>
+          p.installed !== undefined ? p.installed : p.enabled !== false;
+
         const installed = new Set<string>(
           plugins
-            .filter((p: { name: string; enabled?: boolean; installed?: boolean }) =>
-              p.installed !== undefined ? p.installed : p.enabled !== false
-            )
+            .filter(isPluginInstalled)
             .map((p: { name: string }) => p.name)
         );
         setInstalledIds(installed);

         const instMap = new Map<string, string>();
         plugins
-          .filter((p: { name: string; enabled?: boolean; installed?: boolean }) =>
-            p.installed !== undefined ? p.installed : p.enabled !== false
-          )
+          .filter(isPluginInstalled)
           .forEach((p: { name: string; installId?: string; id?: string }) => {

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

# Find package.json files to identify execa version
find . -name "package.json" -type f | head -20

Repository: livepeer/naap

Length of output: 868

---

🏁 Script executed:

# Check the main/root package.json for execa dependency
cat package.json | grep -A 5 -B 5 "execa" || echo "Not found in root"

Repository: livepeer/naap

Length of output: 74

---

🏁 Script executed:

# Also check the plugin-sdk package.json
cat packages/plugin-sdk/package.json | grep -A 5 -B 5 "execa" || echo "Not found in plugin-sdk"

Repository: livepeer/naap

Length of output: 335

---

🏁 Script executed:

# Read the actual file to see the context around lines 52-53
cat -n packages/plugin-sdk/cli/commands/dev.ts | sed -n '40,70p'

Repository: livepeer/naap

Length of output: 1482

---

🌐 Web query:

execa v8 typescript types ExecaChildProcess export

💡 Result:

In execa v8, ExecaChildProcess is not exported anymore (it existed in older major versions, where the return type was literally ExecaChildProcess = ChildProcess & Promise<...>). In newer execa majors, that “child process + promise” concept is modeled with ResultPromise and Subprocess, which are the public exported types. [1], [2], [3]

What to use instead (v8+)

• If you want “the thing returned by execa() / execaCommand() / $” (awaitable + process methods):

import type {ResultPromise} from 'execa';

let p: ResultPromise; // or ResultPromise<YourOptionsType>

• If you specifically want the subprocess (ChildProcess-like) shape:

import type {Subprocess} from 'execa';

let sp: Subprocess; // or Subprocess<YourOptionsType>

Those are the types execa exports from its entrypoint in the current type structure. [1], [2]

Why your import fails: ExecaChildProcess isn’t part of the public exports in v8+, so import type { ExecaChildProcess } from 'execa' will not resolve. [1], [3]

Sources:
[1] Execa entrypoint exports (ResultPromise, Subprocess) https://app.unpkg.com/execa%409.6.0/files/index.d.ts
[2] Subprocess type docs/definition (shows the current public type) https://www.jsdocs.io/package/execa
[3] Older execa versions exported ExecaChildProcess (example from v2.x types) https://app.unpkg.com/execa%402.0.1/files/index.d.ts

---

🌐 Web query:

execa 8.0.0 child process type definition typescript

💡 Result:

In execa@8.0.0, the value you get back from async APIs (e.g. execa(), execaCommand(), `$``...```) is both:

• a Promise (resolves/rejects with the execution “result” object), and
• a Node.js child_process instance (with extra helpers like kill(), piping helpers, etc.). [1]

So in TypeScript you generally want to type it as the library’s exported “promise + subprocess” type (named ResultPromise, and the underlying process type Subprocess is also exported). [2]

Example:

import {execa, type ResultPromise, type Subprocess} from 'execa';

const p: ResultPromise = execa`node -v`; // subprocess + promise

const sp: Subprocess = p;               // if you only care about the process side
const result = await p;                 // if you only care about the awaited result

If you were looking for the old-style name: older execa versions exposed an ExecaChildProcess-style alias; in v8 the public typing is centered around ResultPromise/Subprocess instead. [2]

References: [1] [2]

---

🏁 Script executed:

# Check how the processes array is used in the dev.ts file
cat -n packages/plugin-sdk/cli/commands/dev.ts | sed -n '40,150p'

Repository: livepeer/naap

Length of output: 5348

---

🏁 Script executed:

# Search for where processes array items are accessed/used
rg "processes\." packages/plugin-sdk/cli/commands/dev.ts -A 3 -B 1

Repository: livepeer/naap

Length of output: 1059

---

Replace any with the correct execa v8 type for tracked child processes.

The suggested type ExecaChildProcess does not exist in execa v8+. Use ResultPromise instead, which represents the combined Promise + subprocess interface that execa returns:

import type { ResultPromise } from 'execa';

const processes: { name: string; process: ResultPromise }[] = [];

This type correctly reflects how processes are used: awaited with Promise.all(), accessed for .stdout/.stderr, and controlled with .kill().

🤖 Prompt for AI Agents

In `@packages/plugin-sdk/cli/commands/dev.ts` around lines 52 - 53, Replace the
explicit any for the tracked child process type on the processes array with
execa v8's ResultPromise: change the variable declaration for processes
(currently const processes: { name: string; process: any }[] = []) to use
ResultPromise for the process field, and add an import type { ResultPromise }
from 'execa'; so the shape becomes { name: string; process: ResultPromise }[];
this aligns the type with how the code uses the items (awaiting with
Promise.all, reading .stdout/.stderr and calling .kill()) and removes the eslint
no-explicit-any usage.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Attachments are silently dropped.

The convertOptions method omits the attachments field from EmailOptions. If a caller passes attachments, they will be silently ignored without any warning. Either handle attachments in sendMail or throw/log a warning when they're provided but unsupported.

Proposed fix to warn about unsupported attachments

   private convertOptions(options?: EmailOptions): {
     from?: string;
     replyTo?: string;
     cc?: string[];
     bcc?: string[];
   } {
     if (!options) return {};
+    if (options.attachments?.length) {
+      console.warn('SendGrid integration: attachments are not yet supported and will be ignored');
+    }
     const toEmail = (r?: { email: string }) => r?.email;
     return {
       ...(options.from ? { from: toEmail(options.from) } : {}),
       ...(options.replyTo ? { replyTo: toEmail(options.replyTo) } : {}),
       ...(options.cc ? { cc: options.cc.map(r => r.email) } : {}),
       ...(options.bcc ? { bcc: options.bcc.map(r => r.email) } : {}),
     };
   }

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	/** Convert EmailOptions (with EmailRecipient objects) to plain string fields for sendMail */
	private convertOptions(options?: EmailOptions): {
	from?: string;
	replyTo?: string;
	cc?: string[];
	bcc?: string[];
	} {
	if (!options) return {};
	const toEmail = (r?: { email: string }) => r?.email;
	return {
	...(options.from ? { from: toEmail(options.from) } : {}),
	...(options.replyTo ? { replyTo: toEmail(options.replyTo) } : {}),
	...(options.cc ? { cc: options.cc.map(r => r.email) } : {}),
	...(options.bcc ? { bcc: options.bcc.map(r => r.email) } : {}),
	};
	}
	/** Convert EmailOptions (with EmailRecipient objects) to plain string fields for sendMail */
	private convertOptions(options?: EmailOptions): {
	from?: string;
	replyTo?: string;
	cc?: string[];
	bcc?: string[];
	} {
	if (!options) return {};
	if (options.attachments?.length) {
	console.warn('SendGrid integration: attachments are not yet supported and will be ignored');
	}
	const toEmail = (r?: { email: string }) => r?.email;
	return {
	...(options.from ? { from: toEmail(options.from) } : {}),
	...(options.replyTo ? { replyTo: toEmail(options.replyTo) } : {}),
	...(options.cc ? { cc: options.cc.map(r => r.email) } : {}),
	...(options.bcc ? { bcc: options.bcc.map(r => r.email) } : {}),
	};
	}

🤖 Prompt for AI Agents

In `@packages/plugin-sdk/src/integrations/email/sendgrid.ts` around lines 87 -
102, The convertOptions method currently drops EmailOptions.attachments
silently; update the implementation so attachments are not ignored: either map
options.attachments into SendGrid-compatible attachment objects and include them
in the payload sent by sendMail (add handling in sendMail and propagate from
convertOptions), or detect options.attachments in convertOptions/sendMail and
emit a clear warning or throw an error when attachments are present (use the
existing logger or throw to make it explicit). Refer to the EmailOptions type
and the convertOptions and sendMail functions when adding this
detection/translation so callers no longer lose attachments silently.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Guard selectedRequest rollback against stale selection

At Line 215, the error handler uses selectedRequest from the closure to decide whether to update the modal, but setSelectedRequest mutates whatever is currently selected. If the user switches requests before the API error arrives, the rollback can alter the wrong request. Add an ID check inside the setter to avoid mutating a different selection.

✅ Suggested fix

-        if (selectedRequest?.id === request.id) {
-          setSelectedRequest((prev) => {
-            if (!prev) return prev;
+        if (selectedRequest?.id === request.id) {
+          setSelectedRequest((prev) => {
+            if (!prev || prev.id !== request.id) return prev;
             if (alreadyCommitted) {
               return {
                 ...prev,
                 softCommits: [
                   ...prev.softCommits,

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	if (selectedRequest?.id === request.id) {
	setSelectedRequest((prev) => {
	if (!prev) return prev;
	if (alreadyCommitted) {
	return {
	...prev,
	softCommits: [
	...prev.softCommits,
	{
	id: `sc-${Date.now()}`,
	userId: user.id,
	userName: user.name,
	timestamp: new Date().toISOString(),
	},
	],
	};
	}
	return {
	...prev,
	softCommits: prev.softCommits.filter((sc) => sc.userId !== user.id),
	};
	});
	if (selectedRequest?.id === request.id) {
	setSelectedRequest((prev) => {
	if (!prev || prev.id !== request.id) return prev;
	if (alreadyCommitted) {
	return {
	...prev,
	softCommits: [
	...prev.softCommits,
	{
	id: `sc-${Date.now()}`,
	userId: user.id,
	userName: user.name,
	timestamp: new Date().toISOString(),
	},
	],
	};
	}
	return {
	...prev,
	softCommits: prev.softCommits.filter((sc) => sc.userId !== user.id),
	};
	});

🤖 Prompt for AI Agents

In `@plugins/capacity-planner/frontend/src/pages/Capacity.tsx` around lines 215 -
236, The rollback in the API error handler is using setSelectedRequest with a
closure that can mutate the wrong selection if the user switched requests;
inside the setter (the function passed to setSelectedRequest) check that
prev?.id === request.id before applying the softCommits addition/removal logic
(using selectedRequest, request.id, alreadyCommitted, user.id for context) and
if the IDs differ simply return prev to avoid mutating a stale selection.