Refactor error handling and update options

[whereisfarukk]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello @whereisfarukk, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request focuses on enhancing the robustness and user experience of the VlmRun node. It refactors internal error handling mechanisms to provide more specific and actionable feedback within the workflow environment. Concurrently, it reorganizes the presentation of available operations to users, aiming for a more intuitive interface.

Highlights

• Error Handling Refactor: Error handling for schema validation and response format checks has been refactored to use NodeOperationError instead of generic Error objects, providing more specific context within the n8n workflow.
• Operation Options Reordering: The order of operations displayed in the VlmRun node has been updated, specifically repositioning 'Chat Completion' and 'Manage Files' for improved logical grouping.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors error handling to use NodeOperationError for better user feedback and reorders some UI options for clarity. The changes are generally good and improve consistency. I've pointed out one area in the error handling logic where a small refactoring could further improve the clarity of error messages presented to the user by separating parsing errors from validation errors.

[gemini-code-assist]

While replacing Error with NodeOperationError is a good step for consistency, placing this validation logic inside the try...catch block (lines 866-921) leads to a confusing experience for the user. This catch block is designed for JSON parsing errors, but it will also catch this validation error and wrap it with the misleading message Invalid JSON format for response_format.... At this stage, the JSON is structurally valid, but semantically incorrect.

This issue also affects the validation on lines 911-914.

To provide clearer error messages, I recommend moving all semantic validation logic outside the try...catch block, which should only be responsible for parsing the JSON string.

Here's a suggested structure:

let parsed: any;
try {
    // ... parsing logic for responseFormatParam
} catch (error) {
    throw new NodeOperationError(
        this.getNode(),
        `Invalid JSON format for response_format: ${error instanceof Error ? error.message : String(error)}`
    );
}

// Perform semantic validation on the 'parsed' object here
if (parsed && typeof parsed === 'object') {
    // ...
    if (userDefinedResponseFormat.type === 'json_schema' && !userDefinedResponseFormat.schema) {
        throw new NodeOperationError(
            this.getNode(),
            'Schema is required when type is "json_schema"',
        );
    }
    // ...
} else if (parsed !== undefined) {
    throw new NodeOperationError(
        this.getNode(),
        'Response format must be an object',
    );
}