Skip to content

fix: source events' userId from the authorizations array in buildSource - #3050

Open
Agi-Asi wants to merge 2 commits into
slackapi:mainfrom
Agi-Asi:fix/build-source-user-authorizations
Open

fix: source events' userId from the authorizations array in buildSource#3050
Agi-Asi wants to merge 2 commits into
slackapi:mainfrom
Agi-Asi:fix/build-source-user-authorizations

Conversation

@Agi-Asi

@Agi-Asi Agi-Asi commented Aug 27, 2026

Copy link
Copy Markdown

Summary

Fixes #2271 — the bug @filmaj confirmed there: for event payloads, buildSource extracts userId from event fields (event.user, channel.creator, subteam.created_by). Those name whoever triggered the event — e.g. the invitee in member_joined_channel — who may never have installed the app. authorize() / fetchInstallation() then look up an installation keyed on the wrong user, which breaks apps with multiple user-token installations per team: the installation store cannot know which installation the event was actually delivered for.

The envelope's authorizations array names the installing user the event was delivered for, and buildSource already prefers it for teamId and enterpriseId (the asymmetry called out in the issue) — userId was the odd one out. This PR applies the same pattern: prefer authorizations[0].user_id, falling back to the existing event-field extraction when the array is absent (URL-verification and other non-enveloped shapes are unaffected).

Behavior notes:

  • Single-workspace/bot-token apps are unaffected in practice: for them authorizations[0].user_id is the installing user, which is what a single-install authorize keys on (team/enterprise), and the built-in authorize ignores userId entirely.
  • The fallback preserves today's behavior byte-for-byte when authorizations is missing.

Tests: new test/unit/App/build-source.spec.ts covers both paths — authorizations present (installer id wins over event.user) and absent (event.user fallback unchanged). Full run: 479 passing; npm run build, npm run lint (biome), and npm run test:types (tsd) all clean.

Requirements

For event payloads, buildSource extracted userId from event fields
(event.user, channel.creator, subteam.created_by). Those name whoever
*triggered* the event — e.g. the invitee in member_joined_channel —
who may never have installed the app. authorize()/fetchInstallation()
then look up an installation for the wrong user, which breaks
multi-user-token installs: the store can't know which installation the
event was actually delivered for (slackapi#2271).

The envelope's authorizations array names the installing user the
event was delivered for, and buildSource already prefers it for
teamId and enterpriseId — userId was the odd one out. Do the same:
prefer authorizations[0].user_id, falling back to the existing event
field extraction when the array is absent (URL-verification and other
non-enveloped shapes).

Tests cover both paths: authorizations present (installer id wins over
event.user) and absent (event.user fallback unchanged).

Fixes slackapi#2271
@Agi-Asi
Agi-Asi requested a review from a team as a code owner August 27, 2026 12:47
@changeset-bot

changeset-bot Bot commented Aug 27, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: d264a6b

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@slack/bolt Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@salesforce-cla

Copy link
Copy Markdown

Thanks for the contribution! Before we can merge this, we need @Agi-Asi to sign the Salesforce Inc. Contributor License Agreement.

@Agi-Asi Agi-Asi closed this Aug 27, 2026
@Agi-Asi Agi-Asi reopened this Aug 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug: buildSource does not take into account authorizations array when sourcing user_id during user-token retrieval/authorization

1 participant