Summary

When a config change only affects channels.<channel>.accounts.<accountId>.*, the gateway currently plans a full channel restart instead of an account-scoped restart.

This is visible in the reload pipeline even though the lower-level channel lifecycle already supports startChannel(channelId, accountId?) / stopChannel(channelId, accountId?).

In practice, this creates a wider hot-reload disruption window than necessary and can interrupt in-flight channel activity.

Observed behavior

For account-scoped changes such as:

• channels.telegram.accounts.bgworker_bot.*

the reload flow currently resolves to a full channel restart:

• plugin reload rules are prefix-based (reload?: { configPrefixes: string[]; noopPrefixes?: string[] })
• the reload plan stores channel restarts as restartChannels: Set<ChannelKind>
• plugin hits become restart-channel:${plugin.id}
• hot reload handlers apply:
  • await stopChannel(name)
  • await startChannel(name)

For Telegram, this was observed to restart the entire Telegram channel and produce a transient failure window during active traffic, including log lines like:

• restarting telegram channel
• telegram sendChatAction failed: Network request for 'sendChatAction' failed!

Expected behavior

If a changed path is strictly account-scoped:

• channels.<channel>.accounts.<accountId>.*

the reload plan should restart only that account when the channel lifecycle supports account-scoped start/stop.

Channel-wide restarts should still be used for:

• channel-global config changes such as channels.telegram.replyToMode
• mixed changes where a full channel restart is still required

Code pointers

Current coarse behavior is driven by:

• src/channels/plugins/types.plugin.ts
• src/gateway/config-reload-plan.ts
• src/gateway/server-reload-handlers.ts

Lower-level account-scoped lifecycle already exists in:

• src/gateway/server-channels.ts

Why this matters

This looks like a gateway reload planning limitation rather than a Telegram-specific implementation detail.

Even when the underlying provider can restart a single account, the current reload framework widens the blast radius to the whole channel.

Scope

This issue is about reload granularity only.

It does not claim that every observed Telegram outage was definitively caused by this behavior, and it does not propose broader reply/typing lifecycle changes in the same fix.