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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 9, 2026 5:06pm

PR Summary

Low Risk
Low risk: only changes the HTTP response body for slack webhooks (success and error paths) while keeping status 200, reducing the chance of Slack modal/view submission failures without affecting other providers.

Overview
Ensures slack webhooks return an empty 200 OK response (instead of JSON like {"message":"Webhook processed"}) so Slack interactive payloads (view_submission, block_actions, etc.) can close modals without errors.

Applies this behavior to both the normal success response path and the error handler in apps/sim/lib/webhooks/processor.ts.

^{Written by Cursor Bugbot for commit 07822d1. Configure here.}

Greptile Summary

This PR fixes a Slack webhook integration issue by returning an empty 200 response (with null body) instead of {"message": "Webhook processed"} for all Slack interactive payloads. Slack's API requires an empty 200 for view_submission and other interactive events — a non-empty JSON body without a response_action field is treated as an unrecognized format and can cause modal errors.

The change is applied in two places inside queueWebhookExecution:

• Success path (~line 1171): after queuing/executing the job, before the default fallback JSON response.
• Error path (~line 1220): in the catch block, to prevent Slack from showing an error dialog even when server-side processing fails (errors are still logged).

The fix is well-scoped: Slack's url_verification challenge is handled upstream (in handleSlackChallenge, called before queueWebhookExecution), so the empty-200 shortcut here will never accidentally swallow a challenge response.

Key points:

• The placement of both Slack checks is correct — they follow the existing microsoft-teams provider pattern and fall before the twilio_voice and default branches.
• foundWebhook is a function parameter, so it is always defined in both the try and catch scopes.
• Returning 200 on the error path is a deliberate UX trade-off: Slack errors are logged server-side but not surfaced to the end-user, which avoids confusing Slack error dialogs.

Confidence Score: 5/5

• This PR is safe to merge — the change is narrow, well-commented, and aligns with Slack's documented requirements for interactive payload responses.
• The diff is 12 lines across two symmetrical additions. The Slack url_verification flow is unaffected (handled upstream). foundWebhook is always in scope. The intentional 200-on-error trade-off is clearly documented in comments. No existing tests cover this provider-specific response path and no new tests were added, but the logic is simple enough that manual verification is sufficient.
• No files require special attention.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Slack
    participant Webhook Route
    participant queueWebhookExecution
    participant Job Queue

    Slack->>Webhook Route: POST /webhooks/trigger/{path}
    Note over Webhook Route: handleSlackChallenge()<br/>(url_verification handled here)
    Webhook Route->>queueWebhookExecution: foundWebhook, body, ...

    alt Success path
        queueWebhookExecution->>Job Queue: enqueue('webhook-execution', payload)
        Job Queue-->>queueWebhookExecution: jobId
        Note over queueWebhookExecution: provider === 'slack'
        queueWebhookExecution-->>Slack: 200 (empty body)
        Note over Slack: Modal closes cleanly ✓
    else Error path (catch block)
        queueWebhookExecution->>queueWebhookExecution: logger.error(...)
        Note over queueWebhookExecution: provider === 'slack'
        queueWebhookExecution-->>Slack: 200 (empty body)
        Note over Slack: No error dialog shown to user
    end

_{Last reviewed commit: a9e7f36}

@greptile