Fixes #6736

Why

While reading the WeCom channel's inbound file gate I noticed that allowed_file_extensions can be configured and silently do nothing. Writing it as a scalar, which is the natural way to express a one-item restriction in YAML:

channels:
  wechat:
    allowed_file_extensions: ".pdf"

makes _coerce_str_set fall into if not isinstance(value, (list, tuple, set, frozenset)): return set(default) — a string is not one of those containers — so the channel ends up admitting all 37 built-in extensions instead of only .pdf. There is no log line saying the configured value was unreadable, so the operator has no way to see that the restriction they wrote was dropped.

The pain is the direction of the failure. This set gates which files the Gateway may read; a restriction that widens instead of narrowing is a posture change that is invisible in the logs.

What changed

• allowed_file_extensions: ".pdf" now means exactly that — a bare string is the single entry it names, matching what the sibling _coerce_host_suffixes already accepts one method below.
• When a configured value still cannot be read as an extension allowlist (wrong type, or a list with no usable entries), the channel falls back to the built-in defaults and logs what it ignored and how many extensions it fell back to, so the operator can see the restriction did not take effect.
• Entries that are not strings are reported and skipped instead of being stringified into members like .123 that no real file can ever match.

Behaviour for a well-formed list config is unchanged, and an unset allowed_file_extensions still resolves to the same 37 defaults.

Surface area

• Backend API — endpoint / SSE event / request-response shape under backend/app
• Frontend UI — page / component / setting / interaction under frontend/
• Agents / LangGraph — agent node, graph wiring, langgraph.json, or prompt change
• Sandbox — docker/ or sandboxed execution
• Skills — change under skills/
• Dependencies — new/upgraded entry in backend/pyproject.toml or frontend/package.json (say what it buys us)
• Default behavior change — changes existing behavior without the user opting in (default model, default setting, data shape)
• Docs / tests / CI only — no runtime behavior change

Only an operator who configured allowed_file_extensions as a scalar or with non-string entries notices a difference — and for them the change is that their configured restriction starts applying.

Bug fix verification

• Test path that reproduces the bug: backend/tests/test_wechat_allowed_file_extensions.py
• Did it go red on main and green on this branch? yes

On main (c89fed0b) with the fix reverted:

3 failed, 4 passed

• test_scalar_extension_config_narrows_the_allowlist — .pdf produced 37 extensions
• test_extension_config_of_the_wrong_type_is_logged_before_falling_back — no log emitted
• test_unreadable_extension_entry_is_skipped_and_logged — 123 became a .123 member

On this branch:

7 passed

Validation

From backend/ on Windows, using the repo's own venv (make is not available in this environment, so the underlying commands were run directly):

PYTHONPATH=. python -m pytest tests/test_wechat_allowed_file_extensions.py -q   → 7 passed
PYTHONPATH=. python -m pytest tests/test_wechat_channel.py tests/test_wechat_allowed_file_extensions.py -q
                                                                                → 93 passed, 2 skipped
python -m ruff check app/channels/wechat.py tests/test_wechat_allowed_file_extensions.py
                                                                                → All checks passed!
python -m ruff format --check app/channels/wechat.py tests/test_wechat_allowed_file_extensions.py
                                                                                → 2 files already formatted

The 2 skips are pre-existing in tests/test_wechat_channel.py on this host, not introduced here.

AI assistance

Tool(s) used: Qoder

How you used it: Qoder located the coercions and drafted the tests against the observed config shapes; the failing-then-passing test file and the guard were re-run and verified locally, and the accepted shape was matched to the in-file precedent (_coerce_host_suffixes) and to a97772d0 for WeCom's allowed_users.

• I've read and understand every line of this change and take responsibility for it — it's not unreviewed AI output.