fix: address PR review comments

[waleedlatif1]

Summary

• Add try/catch around navigator.clipboard.writeText() in CopyCodeButton to handle permission/focus failures gracefully
• Add missing folder and past_chat cases in resolveResourceFromContext so dragged folders and tasks appear in the resource panel
• Return HTTP 400 (not 500) for Zod validation errors in all 8 Athena API routes, matching the established pattern across 115+ other routes

Test plan

• Verify copy button still works normally and doesn't break when clipboard access is denied
• Drag a folder and a task from sidebar into chat — verify they appear in the resource panel
• Send a malformed request to an Athena API route — verify 400 response

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Apr 8, 2026 7:12am

[cursor]

PR Summary

Medium Risk
Broad but mechanical change across many API routes that alters client-visible HTTP status codes and error payloads for invalid requests; functional logic is otherwise unchanged.

Overview
Improves request validation handling across multiple tool API routes (Athena, CloudFormation, CloudWatch, DynamoDB, and third-party integrations) by explicitly catching z.ZodError and returning HTTP 400 with a validation message instead of bubbling into generic 500 responses.

Adds a defensive try/catch around navigator.clipboard.writeText() in CopyCodeButton so clipboard permission/focus failures don’t throw and break the UI flow.

^{Reviewed by Cursor Bugbot for commit 088cf23. Configure here.}

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 088cf23. Configure here.}

[greptile-apps]

Greptile Summary

This PR addresses three stated review comments: (1) wrapping navigator.clipboard.writeText() in a try/catch in CopyCodeButton, (2) adding missing folder and past_chat cases in resolveResourceFromContext, and (3) returning HTTP 400 (not 500) for Zod validation errors across 8 Athena and multiple other API routes. The clipboard and HTTP 400 fixes are implemented correctly. However, the resolveResourceFromContext fix — which the PR description explicitly claims — is not present in any of the 36 changed files; apps/sim/app/workspace/[workspaceId]/home/home.tsx is missing from the changeset and the function still falls through to default: return null for folder and past_chat context kinds.

Key changes:

• CopyCodeButton: graceful try/catch around clipboard API
• 8 Athena routes, 7 CloudFormation routes, 7 CloudWatch routes, 6 DynamoDB routes, plus Google Drive/OneDrive/Outlook/Slack routes: ZodError now returns 400 instead of 500
• Slack, Outlook, Google Drive, and OneDrive ZodError responses also include success: false; Athena/CloudFormation/CloudWatch/DynamoDB do not — inconsistency remains between these two groups

Notable issue: The home.tsx resolveResourceFromContext function still has no folder or past_chat case, so dragged folders and tasks from the sidebar still silently return null and are never added to the resource panel.

Confidence Score: 4/5

Safe to merge for the API 400-fix and clipboard changes, but the claimed resolveResourceFromContext fix was never applied — the stated bug still exists in production.

One P1 gap: the PR description explicitly claims to add folder and past_chat cases to resolveResourceFromContext, but home.tsx is absent from the changeset and the function still returns null for both kinds. Dragging folders and tasks from the sidebar into chat continues to silently fail. The remaining two findings (missing success: false on Athena/DynamoDB/CloudFormation/CloudWatch ZodErrors, and any in the Outlook route) are P2. Score is 4 rather than 5 due to the unfixed P1 from the PR's stated scope.

apps/sim/app/workspace/[workspaceId]/home/home.tsx — the resolveResourceFromContext fix is entirely missing from this PR

Vulnerabilities

No security concerns identified. The navigator.clipboard try/catch is a resilience fix with no security implications. The API routes correctly validate auth via checkInternalAuth before processing requests, and Zod validation errors are now returned as 400 responses (client errors) rather than 500 (server errors), which is the appropriate classification.

Important Files Changed

Filename	Overview
apps/sim/components/ui/copy-code-button.tsx	Clean implementation — navigator.clipboard.writeText() wrapped in try/catch with proper cleanup on unmount
apps/sim/app/api/tools/athena/create-named-query/route.ts	ZodError now correctly returns 400, but error response uses { error: ... } without success: false, inconsistent with success shape { success: true, output: ... }
apps/sim/app/api/tools/cloudformation/describe-stacks/route.ts	ZodError returns 400 correctly; follows the same pattern as other CloudFormation routes in this PR
apps/sim/app/api/tools/cloudwatch/describe-alarms/route.ts	ZodError returns 400; logic for AlarmType enum and StateValue cast looks correct
apps/sim/app/api/tools/dynamodb/query/route.ts	ZodError returns 400; response shape differs from Athena (no success wrapper), consistent with pre-existing DynamoDB pattern
apps/sim/app/api/tools/slack/send-message/route.ts	ZodError returns 400 with success: false; fully consistent with success response shape
apps/sim/app/api/tools/outlook/send/route.ts	ZodError returns 400 with success:false; uses any type for the message object at line 74, violating TypeScript rules
apps/sim/app/api/tools/google_drive/download/route.ts	ZodError returns 400 with success:false; well-structured with DNS validation and pinned-IP security checks

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[User drags item from sidebar] --> B{context.kind}
    B -->|workflow / current_workflow| C[return type: workflow]
    B -->|knowledge| D[return type: knowledgebase]
    B -->|table| E[return type: table]
    B -->|file| F[return type: file]
    B -->|folder missing| G[default: return null]
    B -->|past_chat missing| G
    G --> H[handleContextAdd receives null]
    H --> I[Resource silently NOT added to panel]
    C --> J[addResource called]
    D --> J
    E --> J
    F --> J
    J --> K[Resource appears in panel]

Loading

Comments Outside Diff (2)

1. apps/sim/app/workspace/[workspaceId]/home/home.tsx, line 264-280 (link)

   folder and past_chat cases still missing from resolveResourceFromContext

   The PR description states: "Add missing folder and past_chat cases in resolveResourceFromContext so dragged folders and tasks appear in the resource panel" — but home.tsx is not in the changeset and the fix was never applied. Both context kinds fall through to default: return null, so handleContextAdd receives null and the resource is silently discarded.

   ChatContext defines both:

   | { kind: 'past_chat'; chatId: string; label: string }
   | { kind: 'folder'; folderId: string; label: string }

   And MothershipResourceType supports both 'folder' and 'task'. The missing cases should be:

   case 'folder':
     return context.folderId ? { type: 'folder', id: context.folderId } : null
   case 'past_chat':
     return context.chatId ? { type: 'task', id: context.chatId } : null

   Without this fix, dragging a folder or a task from the sidebar into chat still silently does nothing in the resource panel, exactly as before this PR.

2. apps/sim/app/api/tools/outlook/send/route.ts, line 74 (link)

   any type violates TypeScript rules

   const message: any = { ... } is explicitly prohibited by the project's TypeScript guidelines ("No any — Use proper types or unknown with type guards"). A local interface matching the Microsoft Graph mail message structure would make this type-safe and avoid the implicit spread of any to message.attachments, message.ccRecipients, etc.

   interface GraphMailMessage {
     subject: string
     body: { contentType: string; content: string }
     toRecipients: Array<{ emailAddress: { address: string } }>
     ccRecipients?: Array<{ emailAddress: { address: string } }>
     bccRecipients?: Array<{ emailAddress: { address: string } }>
     attachments?: Array<{
       '@odata.type': string
       name: string
       contentType: string
       contentBytes: string
     }>
   }

_{Reviews (1): Last reviewed commit: "fix(api): add success:false to ZodError ..." | Re-trigger Greptile}

[greptile-apps]

ZodError response missing success: false

All 8 Athena routes, 7 CloudFormation routes, 7 CloudWatch routes, and 6 DynamoDB routes return { error: ... } on ZodError without a success field. Their successful responses all include success: true, so error responses should symmetrically include success: false. The commit title (fix(api): add success:false to ZodError responses for consistency) implies this was intentional, but these 28 routes were not updated.

This same pattern is missing in:

• apps/sim/app/api/tools/athena/get-named-query/route.ts:57
• apps/sim/app/api/tools/athena/get-query-execution/route.ts:66
• apps/sim/app/api/tools/athena/get-query-results/route.ts:77
• apps/sim/app/api/tools/athena/list-named-queries/route.ts:54
• apps/sim/app/api/tools/athena/list-query-executions/route.ts:54
• apps/sim/app/api/tools/athena/start-query/route.ts:71
• apps/sim/app/api/tools/athena/stop-query/route.ts:46
• All CloudFormation, CloudWatch, and DynamoDB routes in the same PR

Suggested change

	if (error instanceof z.ZodError) {
	return NextResponse.json(
	{ error: error.errors[0]?.message ?? 'Invalid request' },
	{ status: 400 }
	)
	}
	if (error instanceof z.ZodError) {
	return NextResponse.json(
	{ success: false, error: error.errors[0]?.message ?? 'Invalid request' },
	{ status: 400 }
	)
	}