Summary
Discord reply suppression still regresses on the current runtime when config contains legacy boolean reply_to_mode: false.
Instead of treating that as off, the runtime falls back to first, so the bot replies to the triggering message again.
This appears to remain reproducible after recent upgrades.
Current environment
- Hermes Agent
v0.14.0 (2026.5.16)
- Runtime repo commit:
5672772da
- Linux
Repro config shape
The current runtime accepts configs like:
display:
platforms:
discord:
reply_to_mode: false
platforms:
discord:
reply_to_mode: false
Expected behavior
Legacy boolean false should normalize to reply mode off, so Discord messages are sent without replying to / referencing the triggering message.
Actual behavior
The runtime still behaves as if reply mode were first.
Runtime evidence
Direct probe on the current runtime:
from gateway.config import PlatformConfig
print(PlatformConfig.from_dict({'enabled': True, 'reply_to_mode': False}).reply_to_mode)
print(PlatformConfig.from_dict({'enabled': True, 'reply_to_mode': 'off'}).reply_to_mode)
print(PlatformConfig.from_dict({'enabled': True}).reply_to_mode)
Current output:
False -> False
off -> off
missing -> first
And Discord adapter logic still does:
self._reply_to_mode: str = getattr(config, 'reply_to_mode', 'first') or 'first'
So boolean False is falsy and falls through to "first".
Why this is a regression / compatibility problem
Older configs or migrated configs can still contain boolean false instead of string off.
That means a user can have a config that semantically intends “do not reply”, but after upgrade the bot starts replying again because the runtime does not normalize the legacy bool value before adapter use.
Suggested fix
Normalize reply_to_mode before it reaches the Discord adapter, for example:
False -> "off"
"off" -> "off"
- missing / malformed ->
"first"
This likely belongs in config normalization / PlatformConfig.from_dict(...) rather than only in the adapter.
Notes
This report intentionally avoids any local project/channel identifiers and focuses only on the runtime/config compatibility issue.
Summary
Discord reply suppression still regresses on the current runtime when config contains legacy boolean
reply_to_mode: false.Instead of treating that as
off, the runtime falls back tofirst, so the bot replies to the triggering message again.This appears to remain reproducible after recent upgrades.
Current environment
v0.14.0 (2026.5.16)5672772daRepro config shape
The current runtime accepts configs like:
Expected behavior
Legacy boolean
falseshould normalize to reply modeoff, so Discord messages are sent without replying to / referencing the triggering message.Actual behavior
The runtime still behaves as if reply mode were
first.Runtime evidence
Direct probe on the current runtime:
Current output:
And Discord adapter logic still does:
So boolean
Falseis falsy and falls through to"first".Why this is a regression / compatibility problem
Older configs or migrated configs can still contain boolean
falseinstead of stringoff.That means a user can have a config that semantically intends “do not reply”, but after upgrade the bot starts replying again because the runtime does not normalize the legacy bool value before adapter use.
Suggested fix
Normalize
reply_to_modebefore it reaches the Discord adapter, for example:False -> "off""off" -> "off""first"This likely belongs in config normalization /
PlatformConfig.from_dict(...)rather than only in the adapter.Notes
This report intentionally avoids any local project/channel identifiers and focuses only on the runtime/config compatibility issue.