Symptom
chat.startStream fails with team_not_found on Enterprise Grid workspaces, even with a non-empty thread_ts. Observed in chinchill-api production (ray-dev, deploy 594817568):
slack_sdk.errors.SlackApiError: (url: https://slack.com/api/chat.startStream, status: 200)
The server responded with: {'ok': False, 'error': 'team_not_found'}
Traceback reaches SlackAdapter.stream() → super().stream() → streamer.append() → chat.startStream.
Workspace context
team_id: T0917KZ3BTK
stored_enterprise_id: E0917L87ZCH
is_enterprise_install: False
- Non-streaming
chat.postMessage succeeds on the same workspace
- Only
chat.startStream returns team_not_found
Likely root cause
chat.startStream requires an explicit team_id for Grid orgs (the per-workspace token alone isn't sufficient), but the adapter's AsyncWebClient (SlackAdapter._get_client()) is created without one. Non-streaming Web API calls succeed because they don't enforce the same constraint.
Relationship to existing PRs
Suggested fix path (pending verification)
- Thread
team_id from the streaming context through to the AsyncWebClient call, either:
- Via the existing
recipient_team_id (preferred — already extracted on the inbound path), or
- Via an explicit
team_id parameter on the chat.startStream call
- Add a regression test mocking an Enterprise Grid workspace where
chat.postMessage succeeds without team_id but chat.startStream requires it.
Workaround in flight
chinchill-api is shipping an interim error-handling fix so a failed final-post on an otherwise-successful streaming run no longer surfaces a false "something went wrong" to the end user. The SDK-side fix is still needed for streaming to actually work on Grid workspaces.
Follow-up
@tony-chinchill-ai offered to attach the full traceback in a follow-up comment. Filed by report-on-PR #89.
Symptom
chat.startStreamfails withteam_not_foundon Enterprise Grid workspaces, even with a non-emptythread_ts. Observed in chinchill-api production (ray-dev, deploy594817568):Traceback reaches
SlackAdapter.stream()→super().stream()→streamer.append()→chat.startStream.Workspace context
team_id:T0917KZ3BTKstored_enterprise_id:E0917L87ZCHis_enterprise_install:Falsechat.postMessagesucceeds on the same workspacechat.startStreamreturnsteam_not_foundLikely root cause
chat.startStreamrequires an explicitteam_idfor Grid orgs (the per-workspace token alone isn't sufficient), but the adapter'sAsyncWebClient(SlackAdapter._get_client()) is created without one. Non-streaming Web API calls succeed because they don't enforce the same constraint.Relationship to existing PRs
thread_tsfix (commit916e532— that handles DM-root threads viapost_messagefallback; this path skips that branch becausedecoded.thread_tsis truthy).recipient_team_idplumbing landed in fix(adapters): Slack streaming team_id + Teams DM Graph conversation IDs (vercel/chat#330, #403) #85 ([chat] fix Slack streaming team ID for interactive payloads vercel/chat#330 port — the interactive-payloadteam.idextraction). Worth checking whether that value is plumbed all the way through tostreamer.append()/chat.startStream.Suggested fix path (pending verification)
team_idfrom the streaming context through to theAsyncWebClientcall, either:recipient_team_id(preferred — already extracted on the inbound path), orteam_idparameter on thechat.startStreamcallchat.postMessagesucceeds withoutteam_idbutchat.startStreamrequires it.Workaround in flight
chinchill-api is shipping an interim error-handling fix so a failed final-post on an otherwise-successful streaming run no longer surfaces a false "something went wrong" to the end user. The SDK-side fix is still needed for streaming to actually work on Grid workspaces.
Follow-up
@tony-chinchill-ai offered to attach the full traceback in a follow-up comment. Filed by report-on-PR #89.