Skip to content

Bug: Discord reply_to_mode: false regresses to first on current runtime #29623

@wyjuven

Description

@wyjuven

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Medium — degraded but workaround existsarea/configConfig system, migrations, profilescomp/gatewayGateway runner, session dispatch, deliveryplatform/discordDiscord bot adaptertype/bugSomething isn't working

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions