feat(slack): resolve channel_name and user_name via Slack API

[waleedlatif1]

Summary

• Populate channel_name and user_name by calling conversations.info and users.info when a bot token is provided
• Previously these fields were always empty strings despite being advertised in the trigger outputs
• Both lookups run in parallel via Promise.all to avoid adding sequential latency

Type of Change

• Bug fix (fields were advertised but never populated)

Testing

Tested manually

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Apr 8, 2026 5:36pm

[cursor]

PR Summary

Low Risk
Low risk: adds best-effort Slack API lookups to enrich webhook payloads; main risk is extra outbound calls/latency and potential rate limiting, with failures safely falling back to empty strings.

Overview
Slack webhook trigger outputs are enriched with resolved names. When a botToken is available, the handler now fetches channel_name via conversations.info and user_name via users.info (preferring real_name) and includes them in formatInput output.

Both lookups run in parallel with Promise.all and are best-effort (log warnings and default to '' on failure), while also normalizing the user field through a userId variable.

^{Reviewed by Cursor Bugbot for commit c5240d3. Configure here.}

[greptile-apps]

Greptile Summary

This PR fixes channel_name and user_name always being empty in Slack trigger outputs by adding two new helper functions (fetchSlackChannelName via conversations.info and fetchSlackUserName via users.info) that are called in parallel when a bot token is present. Error handling is consistent with the existing pattern and no new console.log or relative imports are introduced.

Confidence Score: 4/5

Safe to merge — the change is narrowly scoped, well-guarded against API failures, and has no impact on signature verification or event routing.

Logic is straightforward and mirrors the existing helper pattern. The only deduction is the minor sequential latency for reaction events and the absence of automated test coverage for the new helpers.

No files require special attention beyond the one minor optimization noted in the inline comment.

Vulnerabilities

No security concerns identified. The new Slack API calls target hardcoded https://slack.com/api/ endpoints (no SSRF risk), the bot token is sourced from server-side provider config and never exposed to the client, and both helpers follow the same safe fetch pattern as the pre-existing code.

Important Files Changed

Filename	Overview
apps/sim/lib/webhooks/providers/slack.ts	Adds fetchSlackChannelName and fetchSlackUserName helpers called in parallel via Promise.all; solid error handling and logging; one minor sequential latency opportunity for reaction events

Sequence Diagram

sequenceDiagram
    participant S as Slack
    participant H as slackHandler.formatInput
    participant CI as conversations.info
    participant UI as users.info
    participant RI as reactions.get

    S->>H: Webhook event (body + botToken)
    H->>H: Extract channel, userId, isReactionEvent

    alt isReactionEvent && botToken
        H->>RI: fetchSlackMessageText(channel, ts)
        RI-->>H: message text
    end

    alt botToken present
        par
            H->>CI: fetchSlackChannelName(channel)
        and
            H->>UI: fetchSlackUserName(userId)
        end
        CI-->>H: channel_name
        UI-->>H: user_name
    else no botToken
        H->>H: channelName = '', userName = ''
    end

    H-->>S: FormatInputResult (with channel_name, user_name populated)

Loading

_{Reviews (1): Last reviewed commit: "feat(slack): resolve channel_name and us..." | Re-trigger Greptile}

[greptile-apps]

Sequential API calls for reaction events

For reaction events, fetchSlackMessageText is awaited before the Promise.all for channel and user names, resulting in three sequential async round-trips. All three can be parallelized into a single Promise.all, which is especially useful since reactions.get is only needed when isReactionEvent is true.

Suggested change

	if (isReactionEvent && channel && messageTs && botToken) {
	text = await fetchSlackMessageText(channel, messageTs, botToken)
	}
	const [channelName, userName] = botToken
	? await Promise.all([
	channel ? fetchSlackChannelName(channel, botToken) : Promise.resolve(''),
	userId ? fetchSlackUserName(userId, botToken) : Promise.resolve(''),
	])
	: ['', '']
	const [text, [channelName, userName]] = await Promise.all([
	isReactionEvent && channel && messageTs && botToken
	? fetchSlackMessageText(channel, messageTs, botToken)
	: Promise.resolve(rawEvent?.text as string || ''),
	botToken
	? Promise.all([
	channel ? fetchSlackChannelName(channel, botToken) : Promise.resolve(''),
	userId ? fetchSlackUserName(userId, botToken) : Promise.resolve(''),
	])
	: Promise.resolve(['', ''] as [string, string]),
	])