PR #17060: fix: resolve 7 identified issues [automated]

• Repository: NousResearch/hermes-agent
• Author: Sldark23
• State: open | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/17060

Description (problem / solution / changelog)

Resumo / Summary

Este PR resolve 7 issues identificados no repositório Hermes Agent.

Issues Resolvidos

1. #17048 — Docker tmpfs size override

Arquivos: tools/environments/docker.py

Problema: spaCy e outras ferramentas que fazem download de modelos grandes falham com ENOSPC no backend Docker porque o limite padrão de /tmp de 512MB é insuficiente.

Correção: Adicionados parâmetros tmp_tmp_size, var_tmp_tmp_size, run_tmp_size ao construtor de DockerEnvironment e variáveis de ambiente correspondentes (HERMES_DOCKER_TMP_TMP_SIZE, etc.) para permitir ajuste fino dos limites tmpfs.

2. #17003 — MCP HTTP keepalive

Arquivos: tools/mcp_tool.py

Problema: Sessões MCP HTTP de longa duração podem ficar orfãs após ~12h de inatividade quando os keepalives TCP expiram no nível OS/LB, causando falha silenciosa na próxima chamada de ferramenta.

Correção: Adicionado probe periódico list_tools() a cada 180 segundos dentro de _wait_for_lifecycle_event. Se o probe falhar, dispara reconnect.

3. #17034 — image_edit nao exposto no toolset

Arquivos: tools/image_generation_tool.py, toolsets.py, agent/display.py, hermes_cli/tools_config.py

Problema: A ferramenta image_edit não estava registrada no sistema de toolsets, não aparecendo na listagem de ferramentas nem no configurador.

Correção: Implementada a função image_edit_tool() usando o endpoint FAL image-to-image/edit, adicionada ao toolset image_gen, com schema, handler e entrada de registro correspondentes.

4. #16964 — DingTalk file content crash

Arquivos: gateway/platforms/dingtalk.py

Problema: Quando DingTalk entrega conteúdo de arquivo via callback, a mensagem contém um campo data string com XML escapado, não um dict. O código antigo fazia json.loads(data) expecting dict, causando crash.

Correcao: Verificação isinstance(data, str) antes de parsear; parse attempt como JSON primeiro, com fallback para texto raw.

5. #17013 — QQBot duplicate session entries

Arquivos: gateway/platforms/qqbot/adapter.py

Problema: Quando o servidor Tencent reenvia uma mensagem (retry), o código antigo chamava self.session.update() a cada retry, criando entradas duplicadas no histórico.

Correcao: Adicionada verificação para pular session.update() quando o ID da mensagem é o mesmo que o último processado.

6. #16974 — Termux shebang/env fix

Arquivos: setup-hermes.sh

Problema: #!/usr/bin/env bash não funciona no Termux (bash está em /data/data/com.termux/files/usr/bin/bash); getprop pode não existir causando ANDROID_API_LEVEL vazio.

Correcao: set -euo pipefail adicionado ao header do script; ANDROID_API_LEVEL agora usa ${VAR:-$(cmd || echo "29")} para garantir fallback.

7. #16938 — API server session continuity after compression

Arquivos: gateway/platforms/api_server.py

Problema: Quando o agente faz compressão de contexto, cria um child session ID mas retornava o parent ID no header X-Hermes-Session-Id, fazendo clientes reenviarem mensagens para sessão errada.

Correcao: Chamada db.get_compression_tip() antes de carregar histórico + extração de agent.session_id do resultado para retornar o ID correto no header.

Arquivos Modificados

Branches: Sldark23:fix-7-issues-v2 -> NousResearch/hermes-agent:main

Changed files

• REPORT-fix-7-issues-2026-04-28.md (added, +178/-0)
• agent/display.py (modified, +3/-1)
• agent/file_safety.py (modified, +83/-1)
• cli.py (modified, +6/-2)
• gateway/platforms/api_server.py (modified, +10/-1)
• gateway/platforms/dingtalk.py (modified, +22/-0)
• gateway/platforms/discord.py (modified, +165/-6)
• gateway/platforms/qqbot/adapter.py (modified, +12/-7)
• gateway/run.py (modified, +22/-2)
• hermes_cli/tools_config.py (modified, +1/-1)
• run_agent.py (modified, +2/-1)
• setup-hermes.sh (modified, +3/-2)
• tools/environments/docker.py (modified, +76/-4)
• tools/image_generation_tool.py (modified, +151/-0)
• tools/mcp_tool.py (modified, +39/-4)
• toolsets.py (modified, +2/-2)

PR #17230: fix(dingtalk): extract and resolve download code for file/audio/video callbacks (#16964)

• Repository: NousResearch/hermes-agent
• Author: Tranquil-Flow
• State: open | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/17230

Description (problem / solution / changelog)

What does this PR do?

When a user sends a file (PDF, DOCX, etc.), audio, or video to a DingTalk bot, the dingtalk-stream SDK delivers the CALLBACK and the platform adapter even posts a 🤔 Thinking reaction — but the message never reaches gateway.run's inbound dispatcher. No inbound message log line is emitted, the agent is never invoked, and the user sees the bot silently stuck on Thinking forever (#16964). Plain text messages in the same chat work fine.

Root cause: the dingtalk-stream SDK only knows about text / picture / richText msgtype values explicitly — every other type lands the payload in ChatbotMessage.extensions["content"] rather than on a typed attribute. Two adapter methods needed to be aware of that bucket:

1. _extract_media previously only looked at image_content and rich_text_content, so a single PDF / DOCX / MP3 / video attachment yielded an empty (text, media_urls) pair. The empty-message early-return at the call site then dropped the message — but _send_emotion's 🤔 reaction had already fired, leaving the user staring at the Thinking emoji.

2. _resolve_media_codes runs before _extract_media and is responsible for swapping each download code for a fetchable URL in place. It scanned only image_content / rich_text_content too, so without a corresponding extension-bucket branch the new path in (1) would still emit the raw DingTalk code — the silent drop is gone but document/audio/video handlers downstream cannot actually fetch the attachment.

Fixing both at once means the existing in-place mutation pattern (obj[key] = url) keeps working: _extract_media reads from the same dict _resolve_media_codes mutated, so once both branches exist the emitted MessageEvent.media_urls carries a fetchable URL.

Out of scope (deliberately, to keep this fix minimal):

• the persistent streaming_update_with_options_async NoneType warning the reporter mentioned: separate guard-clause issue around optional AI-Cards configuration, not part of the silent-drop pathway;
• the intermittent unknownError code: 500 from DingTalk's media download API: server-side error on their end (note the requestid in the response), not a Hermes bug.

Related Issue

Fixes #16964

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• gateway/platforms/dingtalk.py — _extract_media: when image_content / rich_text_content produce no media and message.message_type is one of "file" / "audio" / "video", fall back to message.extensions["content"]["downloadCode"] (also accept the snake-case download_code alternative for forward-compat) and route to MessageType.DOCUMENT / AUDIO / VIDEO respectively.
• gateway/platforms/dingtalk.py — _resolve_media_codes: parallel extension-bucket branch that collects extensions["content"]'s downloadCode / download_code keys for the same three msgtype values into the existing codes_to_resolve list, so _fetch_download_url mutates the dict in place and downstream readers see a URL instead of the raw code.
• tests/gateway/test_dingtalk.py — two new test classes:
  • TestExtractMediaFileMessages (sync, 6 cases): file / audio / video / snake-case shapes; the no-download-code edge case (still drops, as before); locks in that the existing image flow is unaffected.
  • TestResolveMediaCodesFileMessages (async, 7 cases): _fetch_download_url is called with the raw code from extensions["content"] (verifies args: code, robot_code, token, dict object identity, key name); end-to-end resolve→extract emits the resolved URL not the raw code; audio / video / snake-case all resolve; the existing image_content path is unaffected; text-message msg_type doesn't trigger the resolver.

How to Test

1. Configure DingTalk with valid Client ID / Client Secret / allowed users, start the gateway: hermes gateway start.
2. From the DingTalk mobile app, send a plain text message to the bot — works fine (control case).
3. From the DingTalk mobile app, send a PDF or DOCX file (with or without accompanying caption text).
4. Before this fix: bot stamps a 🤔 Thinking reaction, then nothing further happens — no inbound message: platform=dingtalk log line, agent never invoked, user is stuck.
5. After this fix: the file's download code is resolved to a URL by _fetch_download_url, _extract_media emits the URL into MessageEvent.media_urls, the gateway dispatches the message normally, and the agent receives the file as a media attachment.

Automated:

pytest tests/gateway/test_dingtalk.py::TestExtractMediaFileMessages tests/gateway/test_dingtalk.py::TestResolveMediaCodesFileMessages tests/gateway/test_dingtalk.py::TestExtractText -q

Result on macOS 15.6 / Python 3.14: 19 passed. Without the fix, both test_file_message_resolves_download_code_to_url and test_extract_media_after_resolve_emits_resolved_url fail with the exact symptom — 'FILE-CODE-XYZ' != 'https://oapi.dingtalk.com/dl/FILE-CODE-XYZ' — confirming they exercise the regression path.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/gateway/test_dingtalk.py -q. The two new test classes (13 cases) all pass; pre-existing failures in TestCardLifecycle reproduce on origin/main without this change and are unrelated to the inbound message path.
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 15.6 (Python 3.14)

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A (extended in-line comments on both _extract_media and _resolve_media_codes to document the extension-bucket bridge; no user-facing docs reference the SDK schema internals)
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A (N/A — no config keys touched)
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A (N/A)
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A (N/A — pure dict access + the existing async SDK call; identical across platforms)
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A (N/A — gateway adapter, not a tool)

Screenshots / Logs

$ pytest tests/gateway/test_dingtalk.py::TestExtractMediaFileMessages tests/gateway/test_dingtalk.py::TestResolveMediaCodesFileMessages tests/gateway/test_dingtalk.py::TestExtractText -q
...................                                                      [100%]
19 passed, 12 warnings in 2.97s

Changed files

• gateway/platforms/dingtalk.py (modified, +47/-0)
• tests/gateway/test_dingtalk.py (modified, +314/-0)