Skip to content

fix: add WhatsApp document fallback extensions#82851

Merged
mcaxtr merged 1 commit into
mainfrom
fix/whatsapp-document-default-extension
May 17, 2026
Merged

fix: add WhatsApp document fallback extensions#82851
mcaxtr merged 1 commit into
mainfrom
fix/whatsapp-document-default-extension

Conversation

@mcaxtr

@mcaxtr mcaxtr commented May 17, 2026

Copy link
Copy Markdown
Member

Summary

  • Add a shared WhatsApp document filename helper that preserves explicit filenames and falls back to MIME-aware defaults.
  • Use the helper for normal document sends and forced image/video-as-document sends.
  • Add regressions for PDF, CSV, unknown MIME, and forced visual document fallbacks.

Verification

  • node scripts/test-projects.mjs extensions/whatsapp/src/inbound/send-api.test.ts extensions/whatsapp/src/send.test.ts -- --reporter=verbose
  • git diff --check
  • .agents/skills/codex-review/scripts/codex-review

Real behavior proof

Behavior addressed: WhatsApp document sends without explicit filenames now use MIME-aware fallback names such as file.pdf, file.csv, and file.png instead of extensionless file.

Real environment tested: Local OpenClaw WhatsApp plugin send-path tests in a linked worktree.

Exact steps or command run after this patch: node scripts/test-projects.mjs extensions/whatsapp/src/inbound/send-api.test.ts extensions/whatsapp/src/send.test.ts -- --reporter=verbose

Evidence after fix: The focused WhatsApp tests passed 59 tests across 2 files, including new assertions for application/pdf -> file.pdf, text/csv -> file.csv, unknown MIME -> file, and forced image/png document delivery -> file.png.

Observed result after fix: OpenClaw builds WhatsApp document payloads with extension-bearing fallback filenames whenever the MIME map has a known extension, while preserving explicit filenames.

What was not tested: I did not live-send to a real WhatsApp recipient; the proof covers the payload metadata passed to the WhatsApp provider boundary.

@openclaw-barnacle openclaw-barnacle Bot added channel: whatsapp-web Channel integration: whatsapp-web size: S maintainer Maintainer-authored PR labels May 17, 2026
@clawsweeper

clawsweeper Bot commented May 17, 2026

Copy link
Copy Markdown
Contributor

Codex review: needs maintainer review before merge.

Summary
The PR adds a WhatsApp document filename helper, routes outbound document fallback names through MIME-to-extension mapping, updates focused send-path tests, and adds a changelog entry.

Reproducibility: yes. from source inspection: current main constructs WhatsApp document payloads with file when no filename is provided, including the forced image/video document path. I did not run tests because this review was read-only.

Real behavior proof
Not applicable: This is a maintainer-labeled/member PR, so the external contributor real-behavior proof gate does not apply; the PR body still reports focused payload-boundary test proof.

Next step before merge
No ClawSweeper repair lane is needed; this active maintainer-labeled PR has no blocking findings and should proceed through normal review, CI, and landing.

Security
Cleared: The diff only changes WhatsApp payload filename metadata and tests; it does not add dependencies, scripts, permissions, secrets handling, or downloaded code paths.

Review details

Best possible solution:

Land this focused maintainer PR after required review and CI; if it lands, use it as the canonical fix for the older fallback-filename PR at #48745.

Do we have a high-confidence way to reproduce the issue?

Yes from source inspection: current main constructs WhatsApp document payloads with file when no filename is provided, including the forced image/video document path. I did not run tests because this review was read-only.

Is this the best way to solve the issue?

Yes. A small WhatsApp-local helper around the existing SDK extensionForMime surface is the narrow maintainable fix and avoids moving channel-specific policy into core.

What I checked:

  • Current main still uses extensionless send-api document fallback: On current main, both the forced document branch and ordinary document branch in createWebSendApi fall back to sendOptions?.fileName?.trim() || "file", so application/pdf without a filename is constructed as file. (extensions/whatsapp/src/inbound/send-api.ts:86, d887eb8dc2cc)
  • Current main forceDocument path also falls back to file: The outbound WhatsApp wrapper currently sets documentFileName ??= media.fileName ?? "file" for forced image/video document delivery, matching the PR’s stated symptom for forced visual document sends. (extensions/whatsapp/src/send.ts:153, d887eb8dc2cc)
  • Current main document media normalization uses file fallback: Document media normalization currently preserves an explicit or URL-derived filename, then falls back to file; generated media URLs without a basename therefore do not get a MIME-derived extension. (extensions/whatsapp/src/outbound-media-contract.ts:124, d887eb8dc2cc)
  • Existing MIME helper supports the requested fallback names: The plugin SDK exposes extensionForMime, and the underlying MIME map contains .png, .pdf, and .csv mappings used by the PR’s fallback helper. (src/media/mime.ts:14, d887eb8dc2cc)
  • PR diff centralizes fallback naming: The PR adds resolveWhatsAppDocumentFileName, imports it into send-api.ts, send.ts, and outbound-media-contract.ts, and leaves explicit filenames preferred before MIME-aware defaults. (extensions/whatsapp/src/document-filename.ts:5, 8500000ead99)
  • PR adds focused regression coverage: The diff updates WhatsApp send tests for PDF, CSV, unknown MIME, generated document media, and forced image/png document fallback behavior. (extensions/whatsapp/src/inbound/send-api.test.ts:111, 8500000ead99)

Likely related people:

  • itsuzef: The recent forceDocument end-to-end change is the closest current-main history for the forced visual document path, and the active changelog credits @itsuzef for that WhatsApp fix. (role: introduced forceDocument behavior; confidence: high; commits: 94ed68bc7688; files: extensions/whatsapp/src/send.ts, extensions/whatsapp/src/inbound/send-api.ts, extensions/whatsapp/src/outbound-media-contract.ts)
  • mcaxtr: The PR commit is authored by @mcaxtr, and current-main WhatsApp history also shows Marcus Castro work on WhatsApp account/default behavior, so they have relevant adjacent context beyond opening this PR. (role: recent WhatsApp area contributor and current proposer; confidence: medium; commits: 8500000ead99, 458a52610a4d; files: extensions/whatsapp/src/document-filename.ts, extensions/whatsapp/src/send.ts, extensions/whatsapp/src/inbound/send-api.ts)
  • Shakker: The central WhatsApp send-file logs include recent runtime-loading work by Shakker immediately before the forceDocument change, making them a secondary routing candidate for plugin runtime boundary questions. (role: recent adjacent runtime contributor; confidence: low; commits: c90e42aaa766; files: extensions/whatsapp/src/send.ts, extensions/whatsapp/src/inbound/send-api.ts, extensions/whatsapp/src/outbound-media-contract.ts)

Remaining risk / open question:

  • No live WhatsApp recipient send was shown; the available proof covers the constructed provider payload, not recipient UI rendering.
  • Some CI check runs were still in progress during inspection, so landing should wait for required checks.

Codex review notes: model gpt-5.5, reasoning high; reviewed against d887eb8dc2cc.

@clawsweeper clawsweeper Bot added the P2 Normal backlog priority with limited blast radius. label May 17, 2026
@mcaxtr mcaxtr merged commit 5040eb5 into main May 17, 2026
117 of 124 checks passed
@mcaxtr mcaxtr deleted the fix/whatsapp-document-default-extension branch May 17, 2026 03:09
masatohoshino added a commit to masatohoshino/openclaw that referenced this pull request May 17, 2026
Moves the CWE-93 sanitization fix from send-api.ts (inlined pre-rebase)
into resolveWhatsAppDocumentFileName() in document-filename.ts, following
upstream PR openclaw#82851's extraction of that helper.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
galiniliev pushed a commit to galiniliev/openclaw that referenced this pull request May 20, 2026
SebTardif pushed a commit to SebTardif/openclaw that referenced this pull request May 24, 2026
SebTardif pushed a commit to SebTardif/openclaw that referenced this pull request May 24, 2026
SebTardif pushed a commit to SebTardif/openclaw that referenced this pull request May 24, 2026
github-actions Bot pushed a commit to Desicool/openclaw that referenced this pull request May 24, 2026
galiniliev pushed a commit to galiniliev/openclaw that referenced this pull request May 25, 2026
SebTardif pushed a commit to SebTardif/openclaw that referenced this pull request May 26, 2026
SebTardif pushed a commit to SebTardif/openclaw that referenced this pull request May 26, 2026
SebTardif pushed a commit to SebTardif/openclaw that referenced this pull request May 26, 2026
mcaxtr pushed a commit to masatohoshino/openclaw that referenced this pull request May 28, 2026
Moves the CWE-93 sanitization fix from send-api.ts (inlined pre-rebase)
into resolveWhatsAppDocumentFileName() in document-filename.ts, following
upstream PR openclaw#82851's extraction of that helper.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
mcaxtr pushed a commit to masatohoshino/openclaw that referenced this pull request May 28, 2026
Moves the CWE-93 sanitization fix from send-api.ts (inlined pre-rebase)
into resolveWhatsAppDocumentFileName() in document-filename.ts, following
upstream PR openclaw#82851's extraction of that helper.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
mcaxtr pushed a commit to masatohoshino/openclaw that referenced this pull request May 28, 2026
Moves the CWE-93 sanitization fix from send-api.ts (inlined pre-rebase)
into resolveWhatsAppDocumentFileName() in document-filename.ts, following
upstream PR openclaw#82851's extraction of that helper.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
mcaxtr pushed a commit to masatohoshino/openclaw that referenced this pull request May 28, 2026
Moves the CWE-93 sanitization fix from send-api.ts (inlined pre-rebase)
into resolveWhatsAppDocumentFileName() in document-filename.ts, following
upstream PR openclaw#82851's extraction of that helper.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
mcaxtr pushed a commit to masatohoshino/openclaw that referenced this pull request May 28, 2026
Moves the CWE-93 sanitization fix from send-api.ts (inlined pre-rebase)
into resolveWhatsAppDocumentFileName() in document-filename.ts, following
upstream PR openclaw#82851's extraction of that helper.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
jameslcowan pushed a commit to jameslcowan/openclaw that referenced this pull request Jun 2, 2026
SYU8384 pushed a commit to SYU8384/openclaw that referenced this pull request Jun 3, 2026
sablehead pushed a commit to sablehead/openclaw that referenced this pull request Jun 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

channel: whatsapp-web Channel integration: whatsapp-web maintainer Maintainer-authored PR P2 Normal backlog priority with limited blast radius. size: S

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant