Skip to main content

Disconnect

Closes the OpenRouter API connection and releases the client session to free up resources.

Common Properties​

  • Name - The custom name of the node.
  • Color - The custom color of the node.
  • Delay Before (sec) - Waits in seconds before executing the node.
  • Delay After (sec) - Waits in seconds after executing node.
  • Continue On Error - Automation will continue regardless of any error. The default value is false.
info

If the ContinueOnError property is true, no error is caught when the project is executed, even if a Catch node is used.

Inputs​

  • Connection Id - The connection identifier from the Connect node to close. This ID was returned as output from the Connect node.

How It Works​

The Disconnect node performs cleanup operations for OpenRouter connections. When executed, the node:

  1. Validates that the Connection Id is not empty
  2. Looks up the stored client session using the Connection Id
  3. Removes the client session from memory
  4. Frees up associated resources

The node completes successfully even if the Connection Id doesn't exist in storage (idempotent behavior).

Requirements​

  • A valid Connection Id from a previous Connect node execution
  • The connection should still be active (not already disconnected)

Error Handling​

The node will return specific errors in the following cases:

  • Empty or missing Connection Id input

The node will NOT fail if:

  • The Connection Id doesn't exist (already disconnected or invalid)
  • This makes the node safe to call multiple times

Usage Notes​

  • Always use Disconnect at the end of your OpenRouter workflow
  • Disconnect is optional but recommended for proper resource management
  • Sessions are automatically cleaned up when flows stop, but explicit cleanup is best practice
  • Safe to call even if the connection is already closed
  • Does not require an active internet connection

Best Practices​

  1. Resource Management:

    • Always pair Connect with Disconnect nodes
    • Place Disconnect at the end of your flow
    • Use Disconnect even if errors occurred during processing

  2. Error Handling:

    • Place Disconnect in a "finally" pattern to ensure cleanup
    • Don't worry about calling Disconnect multiple times
    • Use Continue On Error if Disconnect should never fail the flow

  3. Flow Design:

    • Store Connection Id in message scope for easy access
    • Consider using a single Disconnect for multiple branches
    • Clean up connections before flow termination

Examples​

Example 1: Basic Disconnect​

Input:

  • Connection Id: msg.openrouter_connection

Usage: After completing all OpenRouter operations, call Disconnect to clean up the session.

Example 2: Complete Workflow with Error Handling​

[Connect Node]
    |
    | Connection Id: msg.connection
    |
    v
[Try Block]
    |
    v
[Generate Text] --> Uses msg.connection
    |
    v
[Chat Completion] --> Uses msg.connection
    |
    v
[Catch Block]
    |
    | (handle errors)
    |
    v
[Finally Block]
    |
    v
[Disconnect] --> Uses msg.connection (cleanup always runs)

This pattern ensures the connection is always cleaned up, even if errors occur.

Example 3: Parallel Operations with Single Cleanup​

[Connect Node]
    |
    | Connection Id: msg.connection
    |
    +----> [Generate Text 1] --> Uses msg.connection
    |
    +----> [Generate Text 2] --> Uses msg.connection
    |
    +----> [Generate Text 3] --> Uses msg.connection
    |
    v
[Join/Wait for all to complete]
    |
    v
[Disconnect] --> Uses msg.connection

Multiple operations can share one connection, then clean up once at the end.

Example 4: Safe Disconnect Pattern​

Input:

  • Connection Id: msg.connection || ""

Configuration:

  • Continue On Error: true

Usage: This pattern ensures Disconnect never fails the flow, even with an invalid Connection Id.

When to Skip Disconnect​

You can skip the Disconnect node in these scenarios:

  1. Short-lived Flows: If your flow completes quickly and terminates, automatic cleanup will handle it
  2. Single Operations: When using direct API key input on individual nodes (not using Connect)
  3. Development/Testing: During rapid prototyping when resource cleanup is not critical

However, using Disconnect is always the recommended best practice for production flows.

Technical Details​

  • Disconnect operates on in-memory session storage only
  • No API calls are made to OpenRouter during disconnect
  • The operation is instantaneous
  • Multiple disconnects of the same ID are safe (idempotent)
  • Sessions are scoped to the flow execution context