fix(channels-intelligence): claim deliveries provider-agnostically#5914
Merged
tylerslaton merged 2 commits intoJul 10, 2026
Merged
Conversation
The managed runtime's claimOnce() declared `adapters: [this.cfg.adapter]` (defaulting to "slack"), which Intelligence used to filter claimable deliveries by provider. A runtime serving a bot with both Slack and Teams adapters would therefore never receive the bot's Teams deliveries — they stayed queued forever while Slack worked. The managed runtime is provider-agnostic: it emits abstract render frames and Intelligence renders per the delivery's own reply target. So the claim must not filter by provider. Drop the adapter filter from the claim body; one config-free `intelligenceAdapter()` now serves every channel its bot has attached. Verified end-to-end locally against managed Teams: inbound JWT -> claim -> agent -> render -> Bot Connector egress all succeed with this change.
AlemTuzlak
requested review from
jpr5,
marthakelly,
mme,
ranst91 and
tylerslaton
as code owners
July 10, 2026 17:15
Contributor
📣 Social Copy GeneratorGenerate social media copies (Twitter/X, LinkedIn, Blog Post) for this PR using Claude.
|
@copilotkit/a2ui-renderer
@copilotkit/agentcore-runner
@copilotkit/angular
@copilotkit/channels
@copilotkit/channels-discord
@copilotkit/channels-intelligence
@copilotkit/channels-slack
@copilotkit/channels-teams
@copilotkit/channels-telegram
@copilotkit/channels-ui
@copilotkit/channels-whatsapp
@copilotkit/core
@copilotkit/react-core
@copilotkit/react-native
@copilotkit/react-textarea
@copilotkit/react-ui
@copilotkit/runtime
@copilotkit/runtime-client-gql
@copilotkit/sdk-js
@copilotkit/shared
@copilotkit/sqlite-runner
@copilotkit/voice
@copilotkit/vue
@copilotkit/web-components
@copilotkit/web-inspector
commit: |
Contributor
|
Size Change: 0 B Total Size: 1.17 MB ℹ️ View Unchanged
|
…s-safe)
Follow-up to the provider-agnostic claim change on this branch. Now that the
runtime claims deliveries for every provider its bot has attached, Teams
deliveries flow through the same bridge — and their reply target is a distinct
shape (serviceUrl/conversationId/tenantId, no teamId/channel/threadTs). Deriving
conversationKey from Slack-only fields collapsed every Teams conversation onto
one degenerate key, and conversationKey keys the agent/session
(getOrCreate -> makeAgent), so distinct Teams conversations would share
state/memory.
Make replyTarget a discriminated union (slack|teams) and derive conversationKey
per provider: teams:{tenantId}:{conversationId}, matching Intelligence app-api's
thread_key (OSS-441 slice 2, Intelligence #511) so client and server agree on
conversation identity. Unknown adapters fail loud (the claim loop's existing
catch nacks, not wedges).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
|
Reviewed — the direction is right, and I pushed a follow-up fix to the branch (handoff, since Alem and I work different hours). Detail below. The claim change is correctDropping But it exposed a Slack-only assumption that breaks Teams — fixed in
|
tylerslaton
approved these changes
Jul 10, 2026
tylerslaton
deleted the
alem/channels-intelligence-provider-agnostic-claim
branch
July 10, 2026 19:52
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A managed bot with both a Slack and a Teams adapter attached only ever received its Slack deliveries. Teams deliveries stayed
queuedforever — never claimed, never sent.Root cause
channels-intelligence's runtime claim loop (http-transports.ts→claimOnce()) posted a per-provider filter to/api/bots/listener/claim:app-api filters claimable deliveries by that list (
$adapters IS NULL OR bie.provider = ANY($adapters)), so a runtime declaring only"slack"is never handed the same bot's Teams deliveries.But the managed runtime is provider-agnostic: it emits abstract render frames and Intelligence renders each reply per the delivery's own reply target. There is no reason for the runtime to constrain claims by provider — one
intelligenceAdapter()should serve every channel its bot has attached.Fix
Drop the
adaptersfield from the claim body.adaptersis already optional on the app-api side (absent →NULL→ no provider filter → all providers), so this needs no coordinated backend change.this.cfg.adapteris still used for the heartbeat's declared bots and for egress, both unaffected.Testing
Verified end-to-end locally against a managed Teams bot: inbound Bot Framework JWT → claim → agent run → render → Bot Connector egress all
succeedwith this change. Slack continues to work unchanged.