Problem
When a channel plugin (e.g. @omadia/channel-teams) is upgraded via a hot reinstall (upload a new ZIP → reactivate), the kernel re-registers the plugin's proactive sender but does not reload the channel's inbound message handler module. The bot instance bound to the channel's HTTP route (/api/messages) keeps executing the previously loaded module code until the middleware process is restarted.
Symptom (observed)
The Conductor approve/reject Adaptive Card upgrade is a concrete case:
- The new card renders correctly after reinstall (the proactive sender was hot-swapped to the new code).
- But clicking the card's
Action.Submit button falls through to the orchestrator ("no text found") because the running inbound handler is still the old module without the new parseApprovalValue dispatch.
- Diagnostic logs added to the new inbound code never fire, while the card clearly uses the new render code — proving the two paths run different module versions.
- A full
fly machine restart (fresh process loads the currently-installed version) fixes it immediately.
This is the same module-reload gotcha seen earlier with @omadia/integration-microsoft365 getUserMail: a method added to a sibling integration wasn't visible to an already-active consumer until a process restart.
Impact
- Confusing dev/ops experience: a reinstall appears to take (UI/cards update) but inbound behavior silently runs stale code.
- Easy to mis-diagnose (looks like a parsing/contract bug rather than a stale-module bug).
Expected
A channel hot-reinstall/reactivation should rebind the channel's inbound handler (and any captured sibling-service accessors) to the freshly loaded module — OR the operator UI should clearly surface that a process restart is required for inbound changes to take effect.
Likely area
- Channel activation/reactivation lifecycle (
channelRegistry.activate/deactivate) and how the Bot-Framework adapter / /api/messages route holds its handler instance.
- ES module caching: a version-pathed dynamic
import() loads fresh code on install, but the long-lived bot instance + route binding aren't re-created on reactivation (only the proactive-sender registration is).
Workaround (current)
After installing a channel-plugin version whose inbound code changed, restart the middleware process. A reinstall alone only hot-swaps the proactive sender.
Problem
When a channel plugin (e.g.
@omadia/channel-teams) is upgraded via a hot reinstall (upload a new ZIP → reactivate), the kernel re-registers the plugin's proactive sender but does not reload the channel's inbound message handler module. The bot instance bound to the channel's HTTP route (/api/messages) keeps executing the previously loaded module code until the middleware process is restarted.Symptom (observed)
The Conductor approve/reject Adaptive Card upgrade is a concrete case:
Action.Submitbutton falls through to the orchestrator ("no text found") because the running inbound handler is still the old module without the newparseApprovalValuedispatch.fly machine restart(fresh process loads the currently-installed version) fixes it immediately.This is the same module-reload gotcha seen earlier with
@omadia/integration-microsoft365getUserMail: a method added to a sibling integration wasn't visible to an already-active consumer until a process restart.Impact
Expected
A channel hot-reinstall/reactivation should rebind the channel's inbound handler (and any captured sibling-service accessors) to the freshly loaded module — OR the operator UI should clearly surface that a process restart is required for inbound changes to take effect.
Likely area
channelRegistry.activate/deactivate) and how the Bot-Framework adapter //api/messagesroute holds its handler instance.import()loads fresh code on install, but the long-lived bot instance + route binding aren't re-created on reactivation (only the proactive-sender registration is).Workaround (current)
After installing a channel-plugin version whose inbound code changed, restart the middleware process. A reinstall alone only hot-swaps the proactive sender.