fix: Downscale large images before attaching

[charlesvien]

Problem

Large images (>2000px) fail with a dimension limit error when attached via file picker or drag-and-drop. Cmd+V paste already worked because it pre-downscales through ElectronImageProcessor.

Closes #1889

Changes

1. Add downscaleImageFile tRPC endpoint that reads an on-disk image and downscales via existing ElectronImageProcessor
2. Extract shared downscaleAndPersist helper to deduplicate saveClipboardImage and the new endpoint
3. Route image files in all attachment paths through the downscale pipeline
4. Extract resolveDroppedFile utility to deduplicate drop handler logic across components

How did you test this?

Manually

[charlesvien]

• fix: Downscale large images before attaching #1987 👈 (View in Graphite)
• feat: Show PR and diff status icons on task list items #1986
• fix: Reduce update check interval from 24h to 1h #1985
• fix: Debounce releases and skip empty tags in code workflow #1983
• fix: Fix stacked chevrons in project select dropdowns #1981
• fix: Enrich attachment-only task descriptions for title generation #1980
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
apps/code/src/renderer/features/sessions/components/SessionView.tsx:375-382
**Duplicate drop-handler logic (OnceAndOnlyOnce)**

The async drop-handling loop in `SessionView.tsx` and `TaskInput.tsx` (lines 548–555) is now character-for-character identical. The PR already introduced `resolveDroppedFile` to deduplicate `useTiptapEditor` and the two component drop handlers — this same pattern of iterating files and calling `editorRef.current?.addAttachment` appears verbatim in both components and could be extracted into a shared helper (e.g. `resolveAndAttachDroppedFiles(files, addAttachment)`) to stay consistent with the existing deduplication work.

### Issue 2 of 3
apps/code/src/renderer/features/message-editor/utils/persistFile.ts:71-86
**Inconsistent error handling across drop paths**

When `persistImageFilePath` throws (e.g. image is >50MB or the processor fails), `resolveDroppedFile` silently falls back to the original un-downscaled file path. In `AttachmentMenu.tsx` the same failure surfaces a `toast.error("Failed to attach image")`. For the drop paths in `useTiptapEditor`, `SessionView`, and `TaskInput`, the user gets no feedback that downscaling was skipped and the image may still exceed the upstream dimension limit. At a minimum a toast on the catch branch would align the two paths.

### Issue 3 of 3
apps/code/src/renderer/features/message-editor/tiptap/useTiptapEditor.ts:370-388
**Drop handler now always consumes the event**

`event.preventDefault()` and `return true` are now unconditional. Previously, if every dropped file had no resolvable path (`getFilePath` returns `""`), the handler returned `false`, letting tiptap or the browser handle the drop normally. After this change, any file drop is always swallowed — including cases where all `resolveDroppedFile` calls return `null` — which could silently discard drops of items that don't have an Electron file path attached. This is a minor but real behaviour change worth documenting or guarding.

_{Reviews (1): Last reviewed commit: "Consolidate image constants and unify dr..." | Re-trigger Greptile}

[jonathanlab]

nice one

[charlesvien]

Merge activity

• May 4, 7:17 PM UTC: @charlesvien merged this pull request with Graphite.