Skip to content

feat(app): tag User-Agent with concrete receiver class name (#1150)#2881

Open
tmchow wants to merge 2 commits intoslackapi:mainfrom
tmchow:feat/1150-receiver-type-user-agent
Open

feat(app): tag User-Agent with concrete receiver class name (#1150)#2881
tmchow wants to merge 2 commits intoslackapi:mainfrom
tmchow:feat/1150-receiver-type-user-agent

Conversation

@tmchow
Copy link
Copy Markdown

@tmchow tmchow commented Apr 23, 2026

Summary

Closes #1150.

The Slack team wants to see which receivers bolt-js apps are actually running so they can prioritize missing features based on real usage. Today the only tag the WebClient emits for a bolt app is @slack/bolt/<version>, so every receiver is indistinguishable from every other.

This registers a second addAppMetadata entry whose name includes the concrete receiver class (for example @slack/bolt-HTTPReceiver, @slack/bolt-SocketModeReceiver, @slack/bolt-AwsLambdaReceiver, or the class name of a user-supplied custom receiver). It is registered from the App constructor after this.socketMode is resolved but before new WebClient(...) is constructed, because WebClient snapshots getUserAgent() into its axios headers at construction time. The existing module-load-time addAppMetadata({ name: '@slack/bolt', version }) entry is left in place so the base package tag remains, which keeps existing telemetry consumers working.

addAppMetadata writes to a module-global map inside @slack/web-api, so a Node process that constructs multiple App instances with different receiver types will accumulate both entries in every subsequent WebClient's User-Agent. In single-App processes (the common case) the tag is exact; in multi-App processes the tag set is a superset of the receiver types that App has constructed, which over-attributes but does not under-attribute receiver usage. A tighter per-App scoping would require piping a custom User-Agent through clientOptions and bypassing the module-global metadata path, which is a larger design decision; happy to take that route if you prefer.

Verified with npm run build (clean), npm run lint (Biome, 136 files, no fixes applied), and npm run test:unit (465 tests, including a new receiver-type app metadata case in test/unit/App/basic.spec.ts that asserts addAppMetadata is called with a name ending in -FakeReceiver when an app is built with a custom receiver).

Requirements

@tmchow tmchow requested a review from a team as a code owner April 23, 2026 12:33
@salesforce-cla
Copy link
Copy Markdown

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

@changeset-bot
Copy link
Copy Markdown

changeset-bot Bot commented Apr 23, 2026

🦋 Changeset detected

Latest commit: 5e5b15d

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 Minor

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

@tmchow
Copy link
Copy Markdown
Author

tmchow commented Apr 23, 2026

I signed the CLA

@zimeg zimeg closed this Apr 23, 2026
@zimeg zimeg reopened this Apr 23, 2026
tmchow added 2 commits April 29, 2026 10:04
The App constructor now emits a second `addAppMetadata` entry whose name
includes the receiver's class name (e.g. `@slack/bolt-HTTPReceiver`).
Having the receiver type in outbound WebClient User-Agent strings lets
the Slack team see which receivers are actually deployed in the wild
and prioritize missing features accordingly.

Closes slackapi#1150
@tmchow tmchow force-pushed the feat/1150-receiver-type-user-agent branch from 1190ec3 to 5e5b15d Compare April 29, 2026 17:04
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.

User-Agent should include receiver type

2 participants