feat: slack integration

[brojd]

No description provided.

[claude]

Claude finished @brojd's task in 3m 5s —— View job

---

PR Review: Slack Integration

• Read repository guidelines (CLAUDE.md)
• Gather context on PR changes
• Review backend changes (chatops routes, slack provider, models)
• Review frontend changes (slack page, setup dialogs, shared components)
• Review tests
• Review documentation and API spec changes
• Post comprehensive review

---

Overview

This PR adds Slack as a second ChatOps provider alongside the existing MS Teams integration. The implementation follows the established ChatOpsProvider interface pattern, adding a SlackProvider, webhook routes (events, interactive actions, slash commands), a full frontend setup wizard, and channel/agent binding management UI.

The architecture is well-structured — the new Slack provider slots cleanly into the existing ChatOps framework, and the code reuses shared infrastructure (channel bindings model, ChatOpsManager, access control) rather than duplicating it.

---

Strengths

• Security is solid. The SlackProvider.validateWebhookRequest correctly uses HMAC SHA256 with timingSafeEqual, includes replay attack protection (5-minute timestamp window), and captures the raw body via a preParsing hook before Fastify's JSON parser consumes it. All three Slack endpoints (events, interactive, slash commands) validate signatures before processing.
• User access control is consistent. Every Slack entry point (event webhook, interactive button click, slash command) resolves the sender's email via getUserEmail(), verifies they're a registered Archestra user, and the processMessage flow validates team-based agent access — matching the MS Teams security model.
• Deduplication is well-handled. The in-memory recentlyProcessedSlackEvents map provides a fast first-pass filter for the duplicate message/app_mention events Slack fires, with the database-level ChatOpsProcessedMessageModel.tryMarkAsProcessed() as the authoritative dedup. The map has a safety bound (10K entries with 10% eviction) and 30s TTL.
• Async message processing. The Slack event webhook correctly returns 200 immediately and processes the message asynchronously to stay within Slack's 3-second timeout, with error logging on the background promise.
• Clean frontend UX. The setup wizard with manifest generation, step-by-step instructions, and video guides is polished. The SetupDialog/StepCard extraction creates reusable components shared with the MS Teams flow.

---

Issues & Suggestions

1. Bot token exposed in placeholder text (Low - UX)

platform/frontend/src/components/slack-setup-dialog.tsx:576-578

The StepConfigForm shows the current bot token in the placeholder: Current: ${creds.botToken}. While creds.botToken comes from the status API which returns a masked value (xox•••••••), this pattern is fragile — if the masking logic changes, the real token could leak into the placeholder. Consider using a static placeholder like "Bot token configured" instead.

2. conversations.list pagination not handled (Medium - Functional)

platform/backend/src/agents/chatops/slack-provider.ts:386-390

const result = await this.client.conversations.list({
  types: "public_channel,private_channel",
  exclude_archived: true,
  limit: 999,
});

Slack's conversations.list API paginates results and the limit parameter caps at 1000 per page. For workspaces with >999 channels where the bot is a member, this silently drops channels. The limit: 999 comment suggests awareness of the boundary but doesn't handle the response_metadata.next_cursor for pagination. For a first iteration this is likely acceptable, but worth noting as a known limitation or adding cursor-based pagination.

Fix this →

3. Slack user email cache has no negative caching (Low - Performance)

platform/backend/src/agents/chatops/slack-provider.ts:350-378

The getUserEmail method caches successful email lookups for 5 minutes but doesn't cache negative results (users without email). If a user without a configured email repeatedly messages, every message triggers a Slack API call. Consider caching null results for a shorter TTL (e.g., 1 minute) to reduce API calls.

4. Missing @fastify/formbody dependency documentation (Low - DevEx)

platform/backend/package.json:+1

The Slack interactive and slash command endpoints receive application/x-www-form-urlencoded payloads. The captureSlackRawBody preParsing hook captures the raw body before parsing, but the code relies on Fastify having a form body parser registered. The new @slack/web-api dependency is added, but there's no explicit mention of the form body parser dependency. If @fastify/formbody is already registered globally, this works — but it's worth verifying.

5. Grip icon import unused after refactor (Nit)

platform/frontend/src/app/agent-triggers/slack/page.tsx:8

Grip is imported from lucide-react and is used in the agent table actions. This is fine, just confirming it's intentional — it's used on line 462.

6. Consider extracting shared chatops command handling (Low - Maintainability)

platform/backend/src/routes/chatops.ts

The Slack event webhook (lines 572-661) duplicates some of the pattern from the MS Teams webhook: sender email resolution → user verification → binding lookup → agent selection card / process message. The slash command endpoint also has a similar flow. While the current duplication is manageable, if a third provider is added, consider extracting a shared handleIncomingMessage helper that encapsulates the common flow (resolve email → verify user → check binding → route to selection card or processMessage).

7. SlackAgentSetupDialog and EnableAgentsDialog have duplicated agent toggle logic (Nit)

platform/frontend/src/components/slack-agent-setup-dialog.tsx:55-154 and platform/frontend/src/components/enable-agents-dialog.tsx:22-119

The StepEnableSlack component in SlackAgentSetupDialog and the EnableAgentsDialog have nearly identical agent toggle logic and UI. EnableAgentsDialog is the more generic version (accepts a provider prop). Consider whether SlackAgentSetupDialog step 1 could use EnableAgentsDialog directly or share more of the component.

8. Unused import: Grip` in ms-teams page (Nit - cleanup)

Checking the ms-teams page changes — this is a separate file and already existed. No issue here.

---

Security Review

• HMAC verification: Correctly implemented with timingSafeEqual and replay attack protection. The raw body is captured before JSON parsing to ensure signature verification operates on the exact bytes Slack signed.
• User identity: All three Slack endpoints resolve user email via the Slack users.info API (with caching) and verify against registered Archestra users before processing.
• Access control: The processMessage flow in ChatOpsManager performs team-based agent access validation, consistent with MS Teams.
• Rate limiting: All three Slack webhook endpoints have IP-based rate limiting via the shared isRateLimited utility.
• Config endpoint protection: The PUT /api/chatops/config/slack endpoint is correctly gated behind !config.production || config.isQuickstart, matching the MS Teams config endpoint pattern.
• RBAC: New routes (UpdateSlackChatOpsConfig, RefreshChatOpsChannelDiscovery) are registered in routes.ts and have proper permission entries in access-control.ts.

No security concerns found.

---

Tests Review

• slack-provider.test.ts (565 lines): Comprehensive unit tests covering webhook validation (valid signatures, replay attacks, missing headers, timing-safe comparison), event parsing (messages, app_mentions, bot message filtering, DM handling, thread replies), sendReply, sendAgentSelectionCard, getThreadHistory, getUserEmail (with caching), discoverChannels, and parseInteractivePayload. Good coverage.
• chatops-slash-command.test.ts (246 lines): Integration tests for the slash command endpoint covering /archestra-help, /archestra-status, /archestra-select-agent, and unknown commands, with proper signature validation and user verification mocking.
• chatops-manager.test.ts: Updated with +2/-0 to include the Slack provider in the mock setup.

The test coverage is thorough for a new feature. The Playwright E2E tests all pass (431 passed, 4 flaky).

---

Summary

This is a well-implemented Slack integration that follows the established patterns in the codebase. The security model is consistent, the UI is polished with good guided setup flows, and the test coverage is solid. The issues noted above are mostly minor — the pagination limitation in discoverChannels is the most notable functional gap but is acceptable for an initial release.

Verdict: Looks good to merge with the optional improvements noted above.

[London-Cat]

📊 Reputation Summary

User	Rep	Pull Requests	Activity	Assigned	Core Reactions
brojd	⚡ 1823	89✅ 1🔄 10❌	28 issues, 50 comments	4	—

---

How is the score calculated? Read about it in the Reputation Bot repository 🤖

[github-actions]

Playwright test results

 434 passed
 1 flaky

Details

 435 tests across 48 suites
 5 minutes, 41 seconds
 f46218a

Flaky tests

api › api/llm-proxy/token-cost-limits.spec.ts › LLMProxy-TokenCostLimits-Zhipuai › blocks request when profile token cost limit is exceeded