fix(nextjs-size-limit): surface 413s accurately

[icecrasher321]

Summary

Hitting a size limit error randomly truncates payload making error reporting ad hoc.

Type of Change

• Bug fix

Testing

Tested with @aadamgough

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	Preview	Comments	Updated (UTC)
docs	Skipped			Dec 9, 2025 4:49am

[greptile-apps]

Greptile Overview

Greptile Summary

Added comprehensive error handling for Next.js 10MB request body size limits to prevent truncated payloads and provide accurate 413 error reporting.

Key Changes:

• Added proactive request body size validation using validateRequestBodySize() function that checks size before sending requests
• Implemented explicit HTTP 413 status code detection in all three request handlers (handleInternalRequest, handleProxyRequest, executeMcpTool)
• Added isBodySizeLimitError() helper to detect size-related errors from various error messages
• Added handleBodySizeLimitError() in catch blocks to transform cryptic size errors into user-friendly messages
• Consistent error message across all paths: "Request body size limit exceeded (10MB). The workflow data is too large to process. Try reducing the size of variables, inputs, or data being passed between blocks."

Implementation Approach:
The fix uses a defense-in-depth strategy with three layers:

1. Proactive validation: Check body size before sending request (lines 619, 836, 993)
2. Response status checking: Explicitly handle HTTP 413 responses (lines 633-639, 846-849, 1012-1024)
3. Error message pattern matching: Catch size-related errors in catch blocks using pattern matching (lines 739, 891, 1082-1095)

Confidence Score: 4/5

• Safe to merge with minor Node.js compatibility consideration
• The implementation is thorough and follows a defense-in-depth approach with three layers of protection. The code is well-documented with TSDoc comments and consistently handles the error case across all request paths. However, the use of Blob API for size calculation (line 45) may have compatibility issues in older Node.js environments, though this is a best practice consideration rather than a critical bug. The fix addresses the stated problem of random payload truncation and provides clear, actionable error messages to users.
• No files require special attention - the single file change is comprehensive and well-structured

Important Files Changed

File Analysis

Filename	Score	Overview
apps/sim/tools/index.ts	4/5	Added comprehensive 413 error handling with proactive size validation and user-friendly error messages across three request handlers (internal, proxy, MCP). One potential Node.js compatibility issue with Blob API usage.

Sequence Diagram

sequenceDiagram
    participant Client as Client/Executor
    participant executeTool as executeTool()
    participant handler as Request Handler
    participant validate as validateRequestBodySize()
    participant api as External/Internal API
    
    Client->>executeTool: Call with toolId & params
    executeTool->>handler: Route to handler (internal/proxy/mcp)
    
    alt Before Request
        handler->>validate: Check body size
        validate->>validate: Calculate size with Blob API
        alt Size > 10MB
            validate-->>handler: throw Error(user-friendly message)
            handler-->>executeTool: Return error response
            executeTool-->>Client: Return ToolResponse with error
        end
    end
    
    handler->>api: Send request
    
    alt Response Status 413
        api-->>handler: HTTP 413 Entity Too Large
        handler->>handler: Check response.status === 413
        handler-->>executeTool: throw Error(user-friendly message)
        executeTool-->>Client: Return ToolResponse with error
    end
    
    alt Other Error
        api-->>handler: Error response
        handler->>handler: catch block
        handler->>handler: handleBodySizeLimitError()
        alt isBodySizeLimitError = true
            handler-->>executeTool: throw Error(user-friendly message)
        else Other error
            handler-->>executeTool: Re-throw original error
        end
        executeTool-->>Client: Return ToolResponse with error
    end
    
    alt Success
        api-->>handler: HTTP 200 OK
        handler-->>executeTool: Return success response
        executeTool-->>Client: Return ToolResponse with data
    end

Loading

[greptile-apps]

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}