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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		May 26, 2026 9:46pm

PR Summary

Low Risk
Small, targeted change to API error classification that reduces risk of leaking third-party error messages; behavior for existing HttpError subclasses should stay the same.

Overview
Introduces an abstract HttpError base class so domain errors that should map to HTTP responses are explicitly typed, following a NestJS/Spring-style pattern.

withRouteHandler now uses instanceof HttpError (instead of reading a statusCode property on any Error) when deciding whether to return the error’s message and status to the client. Untyped errors still get a generic 500.

WorkspaceAccessDeniedError (403) and InvalidFieldError (400) now extend HttpError so they continue to map correctly through the centralized wrapper without relying on duck-typing.

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

Greptile Summary

This PR replaces duck-typing on a statusCode property with a proper instanceof HttpError check in withRouteHandler, closing the theoretical path where a third-party error carrying a statusCode-shaped field could leak its raw message to API clients.

• Introduces HttpError as an abstract base class (abstract readonly statusCode: number) and migrates the two existing typed-error classes — WorkspaceAccessDeniedError (403) and InvalidFieldError (400) — to extend it.
• readTypedErrorStatus now performs a type-safe instanceof HttpError guard and the previously redundant typeof status !== 'number' check is removed since TypeScript already narrows the type.
• RateLimitError in lib/core/rate-limiter/types.ts still extends plain Error with a statusCode field; it is not currently thrown from any withRouteHandler-wrapped route, so there is no active regression, but it sits outside the new hierarchy.

Confidence Score: 5/5

Safe to merge; the change is a targeted, backward-compatible hardening of the route error handler with no altered behavior for existing callers.

Both migrated error classes retain the same statusCode values and message content, so HTTP responses are unchanged. PresignedUrlError is caught by a local try/catch and never reaches withRouteHandler. RateLimitError carries a statusCode field but is not thrown from any route handler in the current codebase, so no response code regresses to 500.

No files require special attention; the only note is lib/core/rate-limiter/types.ts, which defines RateLimitError outside the new HttpError hierarchy, but this class is not thrown from production route handlers today.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Client
    participant withRouteHandler
    participant readTypedErrorStatus
    participant HttpError

    Client->>withRouteHandler: HTTP request
    withRouteHandler->>withRouteHandler: await handler(request, context)
    note over withRouteHandler: throws error

    withRouteHandler->>readTypedErrorStatus: readTypedErrorStatus(error)
    readTypedErrorStatus->>HttpError: error instanceof HttpError?
    alt is HttpError subclass (e.g. WorkspaceAccessDeniedError 403, InvalidFieldError 400)
        HttpError-->>readTypedErrorStatus: true
        readTypedErrorStatus->>readTypedErrorStatus: "check 400 <= statusCode < 600"
        readTypedErrorStatus-->>withRouteHandler: typed status (4xx/5xx)
        withRouteHandler-->>Client: "JSON { error: message } with typed status"
    else plain Error or third-party error
        HttpError-->>readTypedErrorStatus: false
        readTypedErrorStatus-->>withRouteHandler: undefined
        withRouteHandler-->>Client: "JSON { error: 'Internal server error' } 500"
    end

_{Reviews (2): Last reviewed commit: "chore(api): drop unreachable runtime che..." | Re-trigger Greptile}

@greptile

@cursor review