fix(Facebook Graph API Node): Route failed items to the error output

[hammadxcm]

Summary

When Continue (using error output) is selected on the Facebook Graph API node, failed requests were still emitted on the success output instead of the error output.

continueOnFail() was handled, but the errored item was pushed into the main output without an error or pairedItem property:

returnItems.push({ json: { ...errorItem } });

The execution engine (WorkflowExecute.handleNodeErrorOutput) only moves an item to the error output when it carries item.error — or a json shaped exactly like { error } / { error, message } — and uses pairedItem to resolve the originating input item. The Graph API node's error item is a flat object with several keys and no pairedItem, so it was never recognized as an error and stayed on the success path.

This PR attaches the error and pairedItem to the pushed items, following the established node convention (e.g. the JWT node):

• failed request → NodeApiError
• non-JSON string response → NodeOperationError

The existing Graph API error detail is still preserved on the item's json, so the behavior of the regular Continue mode is unchanged.

How to test

1. Add a Facebook Graph API node and set On Error to Continue (using error output).
2. Make a request that fails (e.g. an invalid token or a non-existent node/edge).
3. Execute.
   • Before: the failed item comes out of the main (success) output.
   • After: the failed item comes out of the error output.

Unit tests cover: throwing when continueOnFail is off, routing a failed request to the error output (item has error + pairedItem, Graph detail preserved), and treating a non-JSON string response as an error item.

Related Linear tickets, Github issues, and Community forum posts

Fixes #31699

Review / Merge checklist

• I have seen this code, I have run this code, and I take responsibility for this code.
• PR title and summary are descriptive.
• Tests included.

[cubic-dev-ai]

No issues found across 2 files

Architecture diagram

sequenceDiagram
    participant Engine as Workflow Execution Engine
    participant Node as Facebook Graph API Node
    participant HTTP as Graph API (HTTPS)
    participant ErrorHandler as Engine Error Output Handler

    Note over Engine,ErrorHandler: Error output routing for continueOnFail

    Engine->>Node: execute() with continueOnFail=true
    Node->>HTTP: GET /v23.0/123456/feed

    alt Request succeeds
        HTTP-->>Node: JSON response
        Node->>Node: Parse JSON
        Node-->>Engine: { json: responseData }
        Engine->>Engine: Route to success output
    else Request fails (e.g. 401, 400)
        HTTP-->>Node: Error response (statusCode, body)
        Node->>Node: Catch error, build errorItem
        Node->>Node: Create NodeApiError with error detail
        Node->>Node: Attach error + pairedItem to item
        Node-->>Engine: { json: errorItem, error: NodeApiError, pairedItem }
        Engine->>ErrorHandler: handleNodeErrorOutput()
        ErrorHandler->>ErrorHandler: Detect error property on item
        ErrorHandler-->>Engine: Route item to error output
    else Response is non-JSON string
        HTTP-->>Node: HTML/plain text response
        Node->>Node: Detect non-JSON string
        Node->>Node: Create NodeOperationError
        Node->>Node: Attach error + pairedItem to item
        Node-->>Engine: { json: { message: response }, error, pairedItem }
        Engine->>ErrorHandler: Route to error output
    end

    alt continueOnFail=false
        Node->>Node: Throw error directly
        Node-->>Engine: Rejected promise
        Engine->>Engine: Standard error propagation
    end

Loading

_{Re-trigger cubic}

[n8n-assistant]

Hey @hammadxcm,

Thank you for your contribution. We appreciate the time and effort you’ve taken to submit this pull request.

Before we can proceed, please ensure the following:
• Tests are included for any new functionality, logic changes or bug fixes.
• The PR aligns with our contribution guidelines.

Regarding new nodes:
We no longer accept new nodes directly into the core codebase. Instead, we encourage contributors to follow our Community Node Submission Guide to publish nodes independently.

If your node integrates with an AI service that you own or represent, please email nodes@n8n.io and we will be happy to discuss the best approach.

About review timelines:
This PR has been added to our internal tracker as "GHC-8676". While we plan to review it, we are currently unable to provide an exact timeframe. Our goal is to begin reviews within a month, but this may change depending on team priorities. We will reach out when the review begins.

Thank you again for contributing to n8n.