mirror of
https://github.com/RightNow-AI/openfang.git
synced 2026-07-30 06:32:17 +00:00
Ben Hoverter
faf2cf9211
Layers richer config validation, an explicit adapter allowlist, and a
stricter bridge routing path on top of upstream `d336314` ("binding
rule"), which shipped the same `channel_id` field as our PR #1127 in a
parallel implementation. Replaces upstream's `sender_user_id`/
`platform_id` heuristic with a single source of truth shared between
config validation and routing.
## What changes vs upstream `d336314`
**Data model** (`openfang-types/src/config.rs`)
- `#[serde(deny_unknown_fields)]` on `AgentBinding` so a typo at the
binding level (e.g. `match_rules` plural) fails loudly instead of
silently leaving the rule defaulted to "match everything". Upstream
has it on `BindingMatchRule` only.
- New `pub const CHANNELS_WITH_PLATFORM_ID_AS_CHANNEL` (19 adapters:
discord, slack, telegram, matrix, mattermost, teams, webex,
rocketchat, nextcloud, pumble, revolt, guilded, feishu, lark,
keybase, google_chat, line, twist, flock, twitch). Single source of
truth shared with the bridge — no drift between routing and
validation paths possible. Hybrid adapters (IRC, Zulip) are
excluded; see source comment.
- Startup validation: warn when a binding sets `channel_id` for a
non-supporting adapter, or when `channel_id` is set without
`channel`. Documents the metadata escape hatch in the warning.
- Top-level `KernelConfig` keeps no `deny_unknown_fields` — comment
explains the §5.5 scoping decision so a future reader doesn't
"tighten" it without realizing it would break forward-compat keys.
**Bridge** (`openfang-channels/src/bridge.rs`)
- Replaces upstream's `sender_channel_id()` heuristic ("if metadata has
`sender_user_id` and it differs from `platform_id`, assume
`platform_id` IS the channel") with `binding_context_for(message)`,
which delegates to `ChannelMessage::channel_id()`. The heuristic
worked for Discord/Slack but would fail silently on Matrix, Teams,
Mattermost, Telegram, etc. — adapters whose `platform_id` IS the
channel ID but whose metadata does not happen to set
`sender_user_id` differently.
- Routes both dispatch paths (text + blocks) through
`resolve_with_context` so `guild_id` and `channel_id` bindings can
match. (Upstream's `resolve_with_channel_id` only handled
channel_id.)
**Channels types** (`openfang-channels/src/types.rs`)
- New `ChannelMessage::channel_id()` accessor: reads `platform_id` for
allowlisted adapters, falls back to `metadata["channel_id"]` for
opt-in adapters, else `None`. Case-folds `Custom(...)` variants so
a stray `Custom("Twitch")` cannot silently slip past the allowlist
(the validation path lowercases user input — accessor must match).
**Tests** (+8 in `bridge.rs`, +5 in `config.rs`, +1 in `types.rs`)
- Bridge: Discord/Telegram/Matrix/custom-supported/user-id-only-adapter
/metadata-fallback/guild-id-from-metadata/Email-returns-None
coverage of `binding_context_for` and `channel_id()`.
- Config: typo rejection on both `BindingMatchRule` and `AgentBinding`;
channel_id-without-channel warning; unsupported-adapter warning;
no-warning for discord/slack/telegram.
- Types: `channel_id()` case-insensitivity for Custom variants
including the Lark/Feishu Intl spelling.
**Docs** (`docs/channel-adapters.md`)
- Routing section rewritten: bindings are step 1 in the resolution
order. New "Bindings" subsection documents the rule shape, the
`peer_id` vs `channel_id` distinction (the easy confusion), full
specificity table, the adapter allowlist with the metadata escape
hatch, and the strict-field parsing rule.
## Why this layering instead of replacing d336314
Upstream's commit and our PR #1127 are functionally equivalent on
Discord and Slack. Shipping a richer extension on top is less churn
than ripping out the upstream commit and substituting ours, and keeps
the API surface upstream just added (`resolve_with_channel_id`)
intact for any third-party consumers.
`cargo check --workspace` and `cargo test -p openfang-types -p
openfang-channels --lib` (850 tests) pass.