feat(reborn): add telegram v2 default-off config guard

[serrrfirat]

Split from #3316 (original PR by @nickpismenkov). This is PR 6/7 in the ProductAdapter stack.

Summary

• Add REBORN_TELEGRAM_V2_ENABLED=false default-off config marker.
• Add ChannelsConfig::reborn_telegram_v2_enabled plumbing.
• Add fail-closed v1/v2 Telegram exclusivity validator.
• Does not register production v2 routes or change legacy v1 Telegram behavior.

Stack

• Depends on feat(reborn): add telegram v2 product adapter tracer bullet #3355.
• Base branch: split/pr3316-05-telegram-v2-product-adapter.

Authorship

Split commits retain Co-authored-by: Nikolay Pismenkov <nickpismenkov@gmail.com>.

Verification

• cargo test --test telegram_v2_default_off_integration --offline --quiet — 5 tests passed.
• cargo test -p ironclaw config::channels::telegram_v2_tests --lib --offline --quiet — 4 tests passed.
• Final stack also ran cargo fmt --all -- --check and targeted ProductAdapter/Telegram/config tests.

[gemini-code-assist]

Code Review

This pull request introduces a feature flag, REBORN_TELEGRAM_V2_ENABLED, to manage the transition between legacy Telegram v1 and the new v2 ProductAdapter, including a validation utility to ensure mutual exclusivity. Feedback suggests integrating this validation directly into the configuration resolution process and refactoring the validator to accept a configuration reference, which would encapsulate the activation logic and reduce the risk of logic drift.

[gemini-code-assist]

Consider calling validate_telegram_v1_v2_exclusivity directly within ChannelsConfig::resolve. Enforcing configuration invariants during resolution ensures that an invalid configuration state is caught as early as possible (e.g., during Config::from_env or Config::from_db). When implementing this, ensure you use a specific error variant like MalformedConfig for these configuration errors to follow the repository's preflight check standards.

References

1. When adding preflight configuration checks, introduce specific error variants (e.g., MalformedConfig) for configuration errors rather than reusing existing, potentially misleading variants.

[gemini-code-assist]

The logic for determining if the legacy Telegram v1 channel is active (checking both wasm_channels_enabled and configured_wasm_channels) is currently described in the docstring but left to the caller to implement. To prevent logic drift and ensure consistency across potential call sites, consider changing this function to take a reference to ChannelsConfig and encapsulating that check within the function body. This would make the validator more robust and easier to use correctly.

[henrypark133]

Finding: the Telegram v1/v2 exclusivity guard misses persisted and hot-activated legacy Telegram channels.

validate_telegram_v1_v2_exclusivity only treats v1 as active when wasm_channels_enabled is true and configured_wasm_channels contains "telegram". But configured_wasm_channels is documented as the setup-wizard startup fallback, separate from runtime activated_channels. Startup loads persisted active WASM channel names from the extension manager, passes them into setup_wasm_channels, and auto-activates persisted WASM channels independently of configured_wasm_channels.

That leaves an existing installation with legacy Telegram active via persisted activated_channels able to start with REBORN_TELEGRAM_V2_ENABLED=true and bypass the fail-closed guard, despite both paths being active for the same webhook installation. Please move/extend the guard to the runtime activation path as well, or feed persisted active channel state into the startup validation, and add coverage for the persisted-active Telegram case.

[Copilot]

Pull request overview

Adds default-off configuration plumbing for the Reborn Telegram v2 ProductAdapter and enforces a fail-closed startup invariant that prevents v1 (legacy WASM channel) and v2 from being enabled for the same Telegram installation at the same time.

Changes:

• Introduce REBORN_TELEGRAM_V2_ENABLED (default false) and plumb it through ChannelsConfig::reborn_telegram_v2_enabled.
• Add validate_telegram_v1_v2_exclusivity() and invoke it from ChannelsConfig::resolve() to enforce v1/v2 mutual exclusivity at config resolution time.
• Add integration + unit tests to pin the default-off behavior and exclusivity matrix; update test helpers to include the new config field.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
tests/telegram_v2_default_off_integration.rs	Adds caller-level integration coverage for the v1/v2 exclusivity validator and default-off contract.
src/tunnel/mod.rs	Updates channel-config test helpers to include the new reborn_telegram_v2_enabled field.
src/config/mod.rs	Re-exports the validator and ensures Config::for_testing() defaults v2 to disabled.
src/config/channels.rs	Adds reborn_telegram_v2_enabled, parses REBORN_TELEGRAM_V2_ENABLED, and enforces v1/v2 exclusivity during resolve; adds unit tests.
Cargo.toml	Extends workspace exclude list (now includes a v2 Telegram path).
.env.example	Documents the new default-off env flag and the fail-closed startup behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[nickpismenkov]

Pushed af4dfa160 (merge) + 284eff06e (review fixes). Summary:

@henrypark133 — persisted-active v1 gap (your finding):

You're right — the env-only guard let an installation with persisted activated_channels.telegram = true start up alongside REBORN_TELEGRAM_V2_ENABLED=true even when WASM_CHANNELS did not list telegram. setup_wasm_channels auto-loads persisted-active channels independently of the env list, so both paths would have stood up for the same webhook installation.

Fix:

• validate_telegram_v1_v2_exclusivity now takes Option<&HashSet<String>> carrying the persisted-active WASM channel set. v1 is active when wasm_channels_enabled && (telegram listed in env OR telegram in persisted-active). The Option lets ChannelsConfig::resolve continue invoking it env-only (no DB yet) without inventing fake state.
• src/main.rs re-invokes the validator with Some(&startup_active_wasm_channels) right after that set is resolved and before setup_wasm_channels runs. Fail-closed via ? — same ConfigError::InvalidValue returned on either tier, so the existing error variant pins the contract.
• Three new unit tests (config::channels::telegram_v2_tests) and three new caller-tier tests (tests/telegram_v2_default_off_integration.rs) cover the persisted axis: persisted telegram + v2 blocks; persisted non-telegram + v2 allows; persisted telegram with wasm_channels_enabled=false allows (setup is dormant, persisted set is moot).

@copilot — inline findings:

• Move whatsapp channel source to channels-src/ for consistency #1 (tests/...:61 brittle Display assertion): replaced rendered.contains("REBORN_TELEGRAM_V2_ENABLED") + contains("3285") with structural match err { ConfigError::InvalidValue { key, .. } => assert_eq!(key, "REBORN_TELEGRAM_V2_ENABLED") }. Wording changes to the message no longer break the regression.
• feat: adding Web UI #2 (channels.rs:582 env-var clobber): the unsafe set_var / remove_var pair in resolve_rejects_v1_and_v2_telegram_together clobbered any developer-shell value of REBORN_TELEGRAM_V2_ENABLED. Replaced with a local ScopedEnv RAII guard that captures the previous value on set and restores it on drop (still gated by lock_env() so concurrent tests stay serialized).
• Onboarding: show Telegram in channel selection and auto-install bundled channel #3 (Cargo.toml:8 dead workspace exclude): confirmed channels-src-v2/telegram does not exist on this branch and dropped the entry while resolving the reborn-integration merge.

@gemini-code-assist: both findings — (1) fold the validator call into ChannelsConfig::resolve, (2) take &ChannelsConfig and encapsulate the v1-active check inside the function — were already landed in cfd4a3b2a before this round. Today's change preserves both: the function still takes &ChannelsConfig and still derives v1_active/v2_active internally; it just gains a second input axis for the runtime tier.

10 unit tests + 10 integration tests pass; cargo fmt --all --check and cargo clippy --workspace --all-features --tests clean.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

[henrypark133]

Thanks for the follow-up fixes here. I rechecked the current head and the earlier persisted-startup bypass is fixed: startup now re-runs the Telegram v1/v2 exclusivity validator with the persisted activated_channels set before setup_wasm_channels, and the new tests cover the persisted-active Telegram case.

What looks good:

• ChannelsConfig::resolve now rejects env-configured v1 Telegram plus REBORN_TELEGRAM_V2_ENABLED=true.
• Startup now rejects persisted-active telegram plus v2 before the legacy WASM channel is restored.
• The tests cover the persisted-active Telegram case and avoid brittle error-string assertions.
• CI is meaningful and green, and the targeted local tests below passed.

Concerning: hot activation can still bypass the v1/v2 exclusivity guard

The exclusivity check only runs during config resolution and startup. ExtensionManager::activate_wasm_channel can still later activate the legacy telegram WASM channel and persist it without knowing whether reborn_telegram_v2_enabled is true.

That leaves a remaining sequence where the process starts cleanly with v2 enabled and no active v1 channel, then a user activates the legacy telegram extension through /api/extensions/telegram/activate or the equivalent extension activation path. At that point both paths can be enabled for the same Telegram installation despite the startup guard.

Please thread the v2 flag or a small activation policy into the extension/channel activation path and reject activation of the legacy telegram WASM channel when v2 is enabled. Add caller-level coverage for the activation path, not just the validator helper.

Checks I ran:

• git diff --check origin/review-base-pr3356...HEAD
• cargo test --test telegram_v2_default_off_integration -- --nocapture
• cargo test -p ironclaw config::channels::telegram_v2_tests --lib -- --nocapture
• cargo test -p ironclaw extensions::manager::tests::test_activate_wasm_channel_finds_legacy_hyphen_alias --lib -- --nocapture

[nickpismenkov]

Pushed 8a6531591 addressing both new review rounds:

@henrypark133 — hot-activation bypass (your CHANGES_REQUESTED finding)

You're right — the config-resolve and startup-time validators don't cover the runtime path. A clean v2-only boot followed by /api/extensions/telegram/activate (or the ToolDispatcher::dispatch equivalent) would activate the legacy v1 telegram WASM channel alongside v2.

Fix threads the flag through to the activation path itself:

• ExtensionManager gains a reborn_telegram_v2_enabled: AtomicBool field (parallels the existing gateway_mode pattern) with set_reborn_telegram_v2_enabled(bool) / reborn_telegram_v2_enabled() accessors.
• src/app.rs::init_extensions wires the flag right after manager construction, from self.config.channels.reborn_telegram_v2_enabled.
• ExtensionManager::activate_wasm_channel consults the flag before any other work. When true and the canonicalized input equals "telegram", the activation returns ExtensionError::ActivationFailed with a message naming REBORN_TELEGRAM_V2_ENABLED and issue [Reborn] Migrate external channel adapters onto ProductAdapter contract #3285. No channel-runtime lookup, no loader call, no active_channel_names write.
• The guard canonicalizes via ironclaw_common::ExtensionName::new(name) so non-canonical aliases (telegram, future hyphen variants) fail closed at the same shape activation accepts them. (Same canonicalization Copilot asked the validator to apply — applied consistently in both places now.)

Three new caller-level tests drive activate_wasm_channel directly (not just the helper):

• test_activate_wasm_channel_rejects_legacy_telegram_when_v2_enabled — canonical name, v2 flag set, asserts error message names the flag and active_channel_names does not contain telegram.
• test_activate_wasm_channel_rejects_legacy_telegram_with_whitespace_when_v2_enabled — non-canonical telegram, asserts the canonicalization in the guard catches it.
• test_activate_wasm_channel_allows_non_telegram_when_v2_enabled — guard does NOT fire for other channels (slack, discord, …). The v2 exclusivity is targeted, not blanket.

@copilot — validator canonicalization (your inline on channels.rs:503)

Replaced the raw c == "telegram" equality with ExtensionName::new(c).map(|n| n.as_str() == "telegram") so both axes (env-tier configured_wasm_channels and runtime-tier persisted-active set) use the same canonicalization that ExtensionManager does. Pulled into a local is_telegram_after_canonicalize helper so it's applied identically on both branches.

Two new unit tests cover the canonicalization contract on each axis:

• non_canonical_telegram_name_in_configured_list_still_blocks_v2
• non_canonical_telegram_name_in_persisted_set_still_blocks_v2

Both feed telegram (whitespace-padded) and assert the validator rejects.

Verification

• 12 unit tests under config::channels::telegram_v2_tests (was 10 — +2 for canonicalization axes).
• 5 test_activate_wasm_channel_* tests (was 2 — +3 for v2 exclusivity guard).
• 10 caller-level integration tests under tests/telegram_v2_default_off_integration.rs.
• cargo fmt --all --check clean.
• cargo clippy --workspace --all-features --tests zero warnings.

Checks you can re-run:

cargo test -p ironclaw config::channels::telegram_v2_tests --lib -- --nocapture
cargo test -p ironclaw test_activate_wasm_channel --lib -- --nocapture
cargo test --test telegram_v2_default_off_integration -- --nocapture

[henrypark133]

Review: approve Telegram v2 default-off guard

The latest follow-up in 8a6531591 resolves my previous blocker. Runtime activation of the legacy telegram WASM channel now fails closed when REBORN_TELEGRAM_V2_ENABLED=true, and the flag is wired into ExtensionManager from app.rs.

What looks good:

• The config-time and startup-time validators now cover env-configured and persisted-active legacy Telegram channels.
• The activation path itself now rejects hot activation of legacy Telegram while v2 owns the Telegram webhook installation.
• The guard canonicalizes extension names before comparison, so non-canonical Telegram aliases do not bypass the check.
• The targeted config, activation-path, and integration tests pass locally, and CI is green.

Merge-order note:

• This branch still carries stacked Telegram v2 adapter commits from #3355, so #3355 should land first or this branch should be rebased after it lands.