Skip to main content

Disconnect

Closes the connection to the Ollama server and releases the client session resources.

tip

Always use Disconnect at the end of your workflow to properly clean up resources and free memory.

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​

  • Client ID - The Client ID returned from the Connect node. This identifies which Ollama client session to close.

Output​

This node does not produce any output.

Options​

This node does not have any configurable options.

How It Works​

The Disconnect node:

  1. Receives the Client ID from the Connect node
  2. Locates the corresponding client session in memory
  3. Removes the client from the session store
  4. Releases associated resources

Usage Example​

Complete Workflow with Connection Management​

1. Connect
   └─> Client ID: "xyz789..."

2. Pull Model (using Client ID: "xyz789...")
   Input: Model = "llama3"

3. Generate Completion (using Client ID: "xyz789...")
   Input: Model = "llama3"
   Input: Prompt = "Explain RPA in simple terms"
   └─> Response: "RPA stands for..."

4. Disconnect (using Client ID: "xyz789...")
   └─> Connection closed successfully

Requirements​

  • A valid Client ID from a Connect node
  • The client session must still exist (not already disconnected)

Common Use Cases​

  • Closing connections at the end of an automation workflow
  • Cleaning up resources after batch processing multiple AI requests
  • Proper resource management in long-running automations

Tips​

  • Always place Disconnect as the last node in your Ollama workflow
  • Use Continue On Error if you want the workflow to continue even if disconnect fails
  • If you're using Host URL directly in nodes (without Connect), you don't need Disconnect
  • The same Client ID cannot be used after disconnection

Error Handling​

Common errors you might encounter:

  • "Failed to get client ID" - The Client ID input is empty or invalid
  • "Invalid client ID" - The client has already been disconnected or never existed
note

If disconnect fails, the client session will eventually be garbage collected, but it's best practice to explicitly disconnect for proper resource management.

Best Practices​

  • Store the Client ID in a message variable at the start of your workflow
  • Use the same Client ID throughout your automation
  • Add error handling around the Disconnect node to ensure it runs even if previous nodes fail
  • Consider using a Try-Catch-Finally pattern where Disconnect is in the Finally block