Bug : Frontend API error handling can crash when Axios error.response is missing #6466

Describe the bug

Some frontend error handlers directly read error.response.data from Axios errors without checking whether error.response exists.

For example, in packages/ui/src/views/tools/ToolDialog.jsx, multiple catch blocks use:

typeof error.response.data === 'object'
    ? error.response.data.message
    : error.response.data

This works when the backend returns a normal response body, but Axios does not always provide error.response. For network failures, backend downtime, CORS issues, timeouts, or cancelled requests, error.response can be undefined. In those cases, the error handler itself can throw a new runtime error while trying to show the original error message.

The project already has a shared helper in packages/ui/src/utils/errorHandler.js, but it currently handles errors generically and does not safely extract useful Axios response messages such as response.data.message, response.data.error, or string response bodies.

To Reproduce

1. Trigger a frontend API action from the Tools dialog, such as exporting, creating, saving, or deleting a tool.
2. Make the request fail in a way where Axios does not receive a backend response, for example:
   • backend server is unavailable
   • request times out
   • network connection fails
   • CORS or request-level failure occurs
3. The catch block tries to read error.response.data.
4. Since error.response may be undefined, the frontend can throw another error instead of showing the original failure message.

Expected behavior

The frontend should show a safe and useful error message for API failures, even when Axios does not include a response object.

Error handling should support common cases like:

error.response.data.message
error.response.data.error
error.response.data // when it is a string
error.response.status
error.message

It should not crash when error.response or error.response.data is missing.

Screenshots

Not Applicable

Flow

Not Applicable

Use Method

pnpm start

Flowise Version

No response

Operating System

Windows

Browser

Other

Additional context

Suggested fix

Update packages/ui/src/utils/errorHandler.js to be Axios-aware while keeping its existing generic fallback behavior. Components like ToolDialog.jsx can then use:

getErrorMessage(error)

instead of repeatedly accessing:

error.response.data

This would make error handling safer, reduce duplicated logic, and provide more consistent user-facing messages across the frontend.