Skip to content

fix(discord): honor documented env-wins-over-config precedence for require_mention/free_response_channels - #13732

Closed
hclsys wants to merge 1 commit into
NousResearch:mainfrom
hclsys:fix/discord-env-precedence-matches-docs-13685
Closed

fix(discord): honor documented env-wins-over-config precedence for require_mention/free_response_channels#13732
hclsys wants to merge 1 commit into
NousResearch:mainfrom
hclsys:fix/discord-env-precedence-matches-docs-13685

Conversation

@hclsys

@hclsys hclsys commented Apr 21, 2026

Copy link
Copy Markdown

Summary

Fixes #13685. The Discord channel docs state:

Config.yaml settings are applied as defaults — if the equivalent env var is already set, the env var wins.

But `_discord_require_mention` and `_discord_free_response_channels` in `gateway/platforms/discord.py` checked `config.extra` first and only fell back to the env var when config was unset — inverting the documented contract for the two most commonly configured Discord gating fields. Since `require_mention: true` is the default in a fresh `config.yaml`, the env var never wins in practice.

Fix

Swap the order in both helpers: env var read first, config.extra as fallback, hardcoded default last. An empty-string env value is treated as not actively set so unset-vs-empty remains distinguishable (an empty string does not mask a non-empty config list).

Test

Added 6 regression tests in `TestDiscordEnvPrecedenceOverConfig`:

  • env TRUE overrides config FALSE for `require_mention` (and vice versa)
  • config value used when env unset
  • default TRUE when neither set
  • env list overrides config list for `free_response_channels`
  • empty env string falls through to config (unset-vs-empty guard)

All 6 new tests pass locally. Pre-existing async tests in the same file fail due to missing `pytest-asyncio` in the local venv — unrelated to this change (same 20 failures present on `main` without my patch).

Scope

2 private methods in 1 adapter. Pure precedence swap — no new capability. Rule out: I checked `PR #9837` which touches `reply_to_mode` (different field), not a rival for these two fields.

Closes #13685.

…quire_mention/free_response_channels (NousResearch#13685)

The docs for the discord channel state:
  Config.yaml settings are applied as defaults — if the equivalent env
  var is already set, the env var wins.

But the _discord_require_mention and _discord_free_response_channels
helpers checked config.extra first and only fell back to the env var
when config was unset. That inverts the documented contract for the
two most commonly configured Discord gating fields.

Swap the order so the env var is read first (and actively-set values
win over config.yaml), and fall back to config.extra when env is unset.
Treat an empty-string env value as 'not actively set' so unset-vs-empty
remains distinguishable and a fresh install's config.yaml still works.

Add 6 regression tests covering:
  - env TRUE overrides config FALSE (and vice versa) for require_mention
  - config value used when env unset
  - default TRUE when neither set
  - env list overrides config list for free_response_channels
  - empty env string falls through to config (unset-vs-empty guard)
@alt-glitch alt-glitch added type/bug Something isn't working comp/gateway Gateway runner, session dispatch, delivery platform/discord Discord bot adapter area/config Config system, migrations, profiles labels Apr 22, 2026
@hclsys

hclsys commented Apr 23, 2026

Copy link
Copy Markdown
Author

Closing — not pursuing further. Thanks for the triage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/config Config system, migrations, profiles comp/gateway Gateway runner, session dispatch, delivery platform/discord Discord bot adapter type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: config.yaml settings override .env settings, despite doc says the opposite

2 participants