Taskpane encrypt path silently drops or zero-fills unreadable attachments

[dobby-coder]

The taskpane "Encrypt & Send" path and the launchevent one-click path read compose attachments through different code, and only the launchevent one guards against Outlook handing back empty bytes.

src/launchevent/launchevent.ts:325-365 (readUserAttachments) does this explicitly:

// Tenant DLP can scrub attachment bytes (e.g. blocked extensions like
// .exe) while still reporting metadata. Detect: declared size > 0 but
// returned content is empty. We refuse rather than silently encrypt
// a 0-byte attachment.
if ((a.size ?? 0) > 0 && base64Len === 0) {
  throw new Error(`Outlook returned no content for attachment "${a.name}" — ...`);
}

…and it rethrows any per-attachment read failure (line 359-362), so the send gets blocked with a Smart Alert.

The taskpane path has neither guard:

• src/lib/office-helpers.ts:210-217 (readComposeAttachmentBytes) passes content.content straight to base64ToArrayBuffer. An empty string yields a 0-byte ArrayBuffer with no complaint.
• src/taskpane/compose-view.ts:591-610 (collectComposeAttachments) wraps the read in try { … } catch (_e) { // Swallow individual attachment read failures. } and simply omits the attachment from the list.

Consequences on the taskpane path (the only path on Outlook for Mac, per compose-view.ts:181):

1. A DLP-scrubbed attachment is encrypted as a 0-byte file. The recipient decrypts successfully and gets an empty attachment; the sender has no indication anything was lost.
2. Any other read failure drops the attachment entirely from the envelope, and encryptAndPrepareSend then removes the original plaintext attachment from the draft (compose-view.ts:494-500). The bytes are gone from the sent message and from the draft, with no warning.

Both are silent data loss on a path the user explicitly asked to be encrypted.

Suggested fix

Apply the launchevent guard to the taskpane path so the two flows agree:

• In readComposeAttachmentBytes (or in collectComposeAttachments, where the declared a.size is available), reject when a.size > 0 and the returned content is empty.
• Stop swallowing read failures in collectComposeAttachments — let them propagate so encryptAndPrepareSend's existing catch surfaces an error and the draft is left untouched (nothing has been mutated at that point; collectComposeAttachments runs at line 423, before any setBody/removeAttachment).
• The shared logic is a good candidate for a helper in src/lib/ used by both readUserAttachments and collectComposeAttachments, rather than a second copy of the check.
• Add a node:test case covering "declared size > 0, empty content → throws" (pattern file: test/render-body.test.ts).

[dobby-coder]

/dobby fix — Give the taskpane compose path the same empty-attachment guard the launchevent path already has. Add a shared helper (in src/lib/) that rejects when an attachment declares size > 0 but Office.js returns empty content, use it from both readUserAttachments (src/launchevent/launchevent.ts) and collectComposeAttachments (src/taskpane/compose-view.ts), and stop swallowing per-attachment read failures in collectComposeAttachments so they propagate to the existing catch in encryptAndPrepareSend before the draft is mutated. Add a node:test case for "declared size > 0, empty content -> throws". Keep the change to those files; run npm test, npx tsc --noEmit and npx eslint -c eslint.config.mjs --max-warnings=0 "src/**/*.{ts,js}" before opening a draft PR.

[dobby-coder]

On it — I'm adding a shared empty-attachment guard helper in src/lib/, wiring it into both readUserAttachments (launchevent) and collectComposeAttachments (taskpane), and fixing the compose path so per-attachment read failures propagate to encryptAndPrepareSend's catch instead of being swallowed. I'll add the node:test case for the empty-content scenario, run the test/typecheck/lint suite, and open a draft PR once it's clean.

[dobby-coder]

Parked: this is dobby-initiated work coupled to @rubenhensen, who already has 3 dobby PRs waiting for review (budget: 3). I'm not opening another one until some of those merge or close — comment here to re-trigger dobby once there's room.