[Bug]: Buzz adapter cannot deliver generated video attachments

[pr0n]

Bug Description

The Buzz platform adapter cannot deliver locally generated video files.

When Hermes produces an MP4 and routes it through the messaging gateway, the text response reaches Buzz successfully, but the attachment is replaced by:

⚠️ Couldn't deliver the video attachment.

The generated MP4 exists on the Hermes host, is readable, and is a valid video. The failure occurs before the Buzz CLI or relay receives an upload request, so both Buzz Desktop and Buzz iOS display the same fallback warning.

Steps to Reproduce

1. Configure and run the native Hermes Buzz gateway.
2. Pair a Buzz user with the Hermes profile.
3. Send a Buzz DM requesting video generation.
4. Have the agent produce a local MP4, resulting in a MEDIA:<local-path>.mp4 response.
5. Observe the Buzz conversation and Hermes gateway log.

Reproduced with an approximately 9 MB valid MP4.

Expected Behavior

Hermes should upload the local MP4 through the Buzz CLI and deliver it as an attachment to the originating Buzz conversation.

If Buzz does not support inline video playback, it should still be delivered as a downloadable file attachment.

Actual Behavior

The accompanying text is delivered, followed by:

⚠️ Couldn't deliver the video attachment.

The gateway log contains:

WARNING gateway.platforms.base: [Buzz] send_video fallback: native video send unavailable for /home//.hermes/profiles//cache/videos/video.mp4

No Buzz CLI upload is attempted.

Affected Component

Gateway (Telegram/Discord/Slack/WhatsApp)

Messaging Platform (if gateway-related)

No response

Debug Report

A public debug-report upload was not included because this installation contains private relay and profile configuration. A redacted local report can be supplied if needed.

Operating System

Ubuntu 26.04 LTS

Python Version

Python 3.11.15

Hermes Version

Hermes Agent v0.19.1 (2026.7.30) Local checkout: 6ecd335

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

gateway/platforms/base.py routes local video extensions such as .mp4 to:

adapter.send_video(
    chat_id=chat_id,
    video_path=media_path,
    metadata=metadata,
)

The bundled plugins/platforms/buzz/adapter.py implements send() and send_image(), but does not override send_video().

The inherited BasePlatformAdapter.send_video() implementation therefore emits the fallback warning instead of invoking buzz messages send --file.

This is analogous to the missing local-image bridge addressed by PR #74999:
#74999

Proposed Fix (optional)

Add a BuzzAdapter.send_video() override that uploads an existing local video through the Buzz CLI's existing file path:

buzz messages send --channel <chat_id> --file <video_path> --content -

The implementation should:

• preserve caption and reply/thread metadata;
• return the existing SendResult structure;
• retain the Base fallback for missing or invalid local paths;
• avoid exposing host filesystem paths in chat;
• add a regression test exercising the real MEDIA: dispatcher path;
• verify MP4 delivery in Buzz Desktop and Buzz mobile.

Ideally, image and video uploads should share an internal Buzz file-upload helper after PR #74999 lands.

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR

[JonthanaHanh]

Submitted PR #76045 with a fix.

The Buzz adapter was missing send_video() and send_audio() overrides — both now use the same --file upload pattern as the existing send_image().

[GottZ]

This was generated by AI during triage.

Summary

One PR addresses issue #75979. #76045 directly fixes the reported cause by adding the missing Buzz media overrides and routing local video and audio files through the existing CLI file-upload pattern.

Related pull requests

• fix: add send_video and send_audio to Buzz adapter (#75979) #76045 best fix — (+77/-0) — fixes: Adds send_video() and send_audio() to the Buzz adapter; local media now uses messages send --file instead of falling through to the base adapter's warning response, while remote URLs are sent as links.

Suggested consolidation

Merge #76045 as the best available fix for #75979: its diff directly implements the missing Buzz send_video() override responsible for dropping local MP4 attachments and consistently extends the same upload path to audio. There are no competing PRs to close as duplicates.

Complex graph

flowchart LR
    classDef open fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
    classDef merged fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef closed fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    classDef unverified fill:#f3f4f6,stroke:#9ca3af,color:#374151
    classDef best stroke-width:3px,stroke:#b45309
    classDef target stroke-width:3px,stroke:#4338ca
    I75979(["issue #75979 (open)"])
    P76045["PR #76045 (open)"]
    P76045 -->|best fix| I75979
    class I75979 open
    class I75979 target
    class P76045 open
    class P76045 best
    click I75979 "https://github.com/NousResearch/hermes-agent/issues/75979"
    click P76045 "https://github.com/NousResearch/hermes-agent/pull/76045"

Loading

Graph: solid arrow = fixes / best fix, dashed arrow = partial or unverified (see edge label); boxed group = PRs duplicating each other; amber border = best fix; indigo border = target; gray node = closed (state tag in the node label).

Cross-PR triage: Reviewed 1 pull request and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 4 kB of PR diffs, 5 kB of issue/PR text, <1 kB of discussion (1 comments), 2 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.

[teknium1]

Fixed by #99432 (salvaging @chigreen's #95688 with @EmpireOperating's #78046 receipt contract): generated video delivers through native messages send --file with a verified receipt.