fix: add WhatsApp document fallback extensions#82851
Conversation
|
Codex review: needs maintainer review before merge. Summary Reproducibility: yes. from source inspection: current main constructs WhatsApp document payloads with Real behavior proof Next step before merge Security Review detailsBest 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 Is this the best way to solve the issue? Yes. A small WhatsApp-local helper around the existing SDK What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against d887eb8dc2cc. |
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>
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>
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>
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>
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>
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>
Summary
Verification
node scripts/test-projects.mjs extensions/whatsapp/src/inbound/send-api.test.ts extensions/whatsapp/src/send.test.ts -- --reporter=verbosegit diff --check.agents/skills/codex-review/scripts/codex-reviewReal behavior proof
Behavior addressed: WhatsApp document sends without explicit filenames now use MIME-aware fallback names such as
file.pdf,file.csv, andfile.pnginstead of extensionlessfile.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=verboseEvidence 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 forcedimage/pngdocument 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.