#7458: fix: pass filename through to WhatsApp document sends (#7446)
channel: whatsapp-web
Cluster:
WhatsApp Document Handling Fixes
## Summary
Fixes #7446 - When sending documents via WhatsApp, recipients see "file" instead of the actual filename.
## Root Cause
The `filename` parameter wasn't being passed through the WhatsApp send chain. The `send-api.ts` file had a hardcoded `fileName: "file"` for document payloads.
## Changes
1. **`src/channels/plugins/types.adapters.ts`**: Added `filename?: string` to `ChannelOutboundContext` type
2. **`src/web/active-listener.ts`**: Added `fileName?: string` to `ActiveWebSendOptions` type
3. **`src/web/outbound.ts`**:
- Added `fileName` option to `sendMessageWhatsApp`
- Capture `fileName` from `loadWebMedia` result
- Use provided fileName or fall back to the one from loaded media
4. **`src/web/inbound/send-api.ts`**: Use `sendOptions?.fileName || "file"` instead of hardcoded "file"
5. **`src/channels/plugins/outbound/whatsapp.ts`**: Pass `filename` to `sendMessageWhatsApp`
6. **`extensions/whatsapp/src/channel.ts`**: Pass `filename` to `sendMessageWhatsApp`
## Testing
- `pnpm tsgo` - No type errors
- `pnpm lint` - No warnings or errors
The fix ensures that:
1. If a filename is explicitly provided via the message tool, it's used
2. Otherwise, the filename is extracted from the loaded media (via `loadWebMedia`)
3. Falls back to "file" only if neither is available
<!-- greptile_comment -->
<h2>Greptile Overview</h2>
<h3>Greptile Summary</h3>
This PR threads a document filename through the WhatsApp outbound pipeline so recipients see the actual document name instead of a hardcoded `"file"`. It extends the outbound context/types to carry `filename`, maps that to `fileName` in web send options, plumbs it through `sendMessageWhatsApp` (including falling back to `loadWebMedia`’s derived filename), and uses it in the Baileys document payload.
One gap: the existing outbound unit test for document sends (`src/web/outbound.test.ts`) doesn’t assert the new filename propagation, so a regression in this feature wouldn’t be caught by tests.
<h3>Confidence Score: 4/5</h3>
- This PR is safe to merge with low functional risk.
- Changes are small and localized, mainly plumbing a new optional `fileName` through existing WhatsApp send paths. The only notable issue is test coverage not being updated to assert the new behavior, which increases regression risk without affecting runtime correctness directly.
- src/web/outbound.test.ts
<!-- greptile_other_comments_section -->
**Context used:**
- Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8))
- Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13))
<!-- /greptile_comment -->
Most Similar PRs
#10889: fix: pass fileName through WhatsApp document send path
by DeveshParagiri · 2026-02-07
92.3%
#9606: fix: pass fileName to WhatsApp document messages
by AytuncYildizli · 2026-02-05
91.9%
#21881: fix(whatsapp): pass user-provided fileName through document send pipe…
by saakshigupta2002 · 2026-02-20
90.9%
#15650: fix(whatsapp): pass fileName to document sends instead of hardcodin...
by whoknowsmann · 2026-02-13
90.1%
#6566: fix: thread fileName through WhatsApp document send path
by giannisanni · 2026-02-01
89.7%
#16785: fix(whatsapp): preserve document filenames in outbound Baileys mode
by SahilSahu731 · 2026-02-15
89.7%
#16817: fix(whatsapp): infer extension-aware fallback filename for Baileys ...
by VintLin · 2026-02-15
85.9%
#13431: feat(whatsapp): add built-in Markdown to WhatsApp format transform
by asklee-klawd · 2026-02-10
77.6%
#7395: fix(whatsapp): strip markdown bold/italic from URLs before sending
by lailoo · 2026-02-02
77.5%
#23579: feat(whatsapp): add sender attribution to inbound message logs
by svan058 · 2026-02-22
77.5%