fix(webhook): throw webhook errors as 4xxs

[TheodoreSpeaks]

Summary

We recently cought all preprocessResult errors as 5xxs. These can be caused by workflows deleted, usage limit exceeded, rate limit exceeded, etc which are all user errors. Changed this to correctly throw using status and error passed from preprocessResult

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• Other: ___________

Testing

• Manual validation. This is an internal endpoint, and changing from 4xx to 5xx is mostly for metrics and doesn't cause changes in behavior.

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)

Screenshots/Videos

[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 7:10pm

[cursor]

PR Summary

Low Risk
Low risk: change only affects error mapping/logging for polled webhook preprocessing failures, but could alter returned status codes/messages and thus metrics/alerting for polling providers.

Overview
Polled webhook processing now propagates preprocessing failures as their original HTTP status and error message instead of always returning a generic 500.

processPolledWebhookEvent extracts status and JSON { error } from the checkWebhookPreprocessing NextResponse, logs the details, and returns them to polling callers.

^{Reviewed by Cursor Bugbot for commit c82de96. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Greptile Summary

This PR fixes checkWebhookPreprocessing in processor.ts so that errors returned by preprocessExecution propagate their own statusCode (404 for deleted workflows, 403 for undeployed, 429 for rate limits, etc.) rather than being hardcoded to 500. The catch block for genuine unexpected exceptions correctly retains a 500 response.

Confidence Score: 4/5

Safe to merge — the fix correctly propagates preprocessing status codes, the change is minimal and well-scoped, and the catch block still guards against unexpected exceptions.

The logic change is straightforward and correct. The only minor concern is a non-null assertion on an optional TypeScript field that is safe today but could be fragile if the preprocessExecution interface evolves.

apps/sim/lib/webhooks/processor.ts line 453 — non-null assertion on optional error field.

Vulnerabilities

No security concerns identified. Propagating correct HTTP status codes for client errors does not introduce any injection, auth bypass, or data exposure risks.

Important Files Changed

Filename	Overview
apps/sim/lib/webhooks/processor.ts	Fixes checkWebhookPreprocessing to propagate the actual error.statusCode from preprocessExecution instead of hardcoding 500, correctly surfacing 4xx errors for user-caused failures (deleted workflows, rate limits, etc.); uses a non-null assertion on an optional field.

Sequence Diagram

sequenceDiagram
    participant WH as Webhook Route
    participant CP as checkWebhookPreprocessing
    participant PE as preprocessExecution
    participant FPE as formatProviderErrorResponse

    WH->>CP: checkWebhookPreprocessing(workflow, webhook, requestId)
    CP->>PE: preprocessExecution({workflowId, userId, ...})
    alt success === false (user error: deleted, rate-limit, etc.)
        PE-->>CP: {success: false, error: {message, statusCode: 4xx|5xx}}
        CP->>FPE: formatProviderErrorResponse(webhook, error.message, error.statusCode)
        FPE-->>CP: NextResponse (correct 4xx or 5xx)
        CP-->>WH: {error: NextResponse}
    else success === true
        PE-->>CP: {success: true, actorUserId, ...}
        CP-->>WH: {error: null, actorUserId, executionId, correlation}
    else unexpected exception thrown
        PE-->>CP: throws
        CP->>FPE: formatProviderErrorResponse(webhook, 'Internal error during preprocessing', 500)
        FPE-->>CP: NextResponse (500)
        CP-->>WH: {error: NextResponse (500)}
    end

Loading

Comments Outside Diff (1)

1. apps/sim/lib/webhooks/processor.ts, line 453 (link)

   Non-null assertion on optional field

   preprocessResult.error! silences TypeScript's complaint, but the PreprocessExecutionResult interface declares error as optional (error?). While the current implementation of preprocessExecution always supplies an error object when success === false, any future path that returns {success: false} without error will throw at runtime. A defensive fallback is safer.

_{Reviews (1): Last reviewed commit: "fix(webhook): throw webhook errors as 4x..." | Re-trigger Greptile}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

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