Show the plugin error message in the UI toast instead of the raw error envelope

[jakcinmarina]

Self Checks

• I have read the Contributing Guide and Language Policy.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

While testing the credential setup for a tool plugin we maintain
(apify/apify-integration) in Dify Cloud, I pasted an invalid API token to
check what a user would see. The plugin raises a
ToolProviderCredentialValidationError with a message written for exactly that
situation:

Invalid Apify API Token. Please check the token and try again.

What actually appears in the toast is the serialized error envelope with that
message buried inside it:

req_id: a7ce6eaf14 PluginInvokeError: {"args": {},"error_type":"ToolProviderCredentialValidationError","message":"Invalid Apify API Token. Please check the token and try again."}

This is not specific to our plugin. I hit the same thing while configuring
credentials for an unrelated third-party tool plugin, which matches what the
SDK does: it wraps every exception in this envelope regardless of type or
origin.

Nothing is broken here and the message is readable, so this is a polish request
rather than a bug. But it reads as internal debug output rather than as
something written for the person configuring the tool, and my worry is the
non-developer users building apps in Dify, who have to visually parse past
{"args": {},"error_type":...} to reach the sentence meant for them.

What I would like is for the toast to show the message field on its own, with
req_id and error_type still available for diagnostics but out of the
primary text. Since every plugin goes through this same path, that would improve
error UX across all of them at once, not just ours.

2. Additional context or comments

Tested on Dify Cloud (dify.ai) on 2026-08-10, with plugin
apify/apify-integration 1.0.4 and plugin SDK dify_plugin 0.4.5.

The message is already a distinct field by the time it leaves the plugin. The
SDK builds the payload in dify_plugin/core/server/io_server.py:

data={
    "error_type": type(e).__name__,
    "message": str(e),
    "args": args,
}

One thing I would like to confirm: is any of this controllable from the plugin
side? As far as I can tell the SDK wraps every exception in this envelope
unconditionally, with no hook to customize it, and raising a different exception
type only changes error_type. The only thing a plugin author controls is
str(e). If there is a plugin-side option I have missed, I am happy to fix it
on our end instead.

3. Can you help us with this feature?

• I am interested in contributing to this feature.

[KXHXK]

I'd like to work on this. I traced the credential flow and found that the existing parsePluginErrorMessage helper is already used for subscription credentials, while the plugin-auth API-key add/update mutations still rely on the global raw-error toast. I plan to reuse that helper for those two mutations, suppress only their default notification, preserve the rejected response for callers/diagnostics, and add focused regression tests for nested PluginInvokeError messages and fallback errors. Please let me know if you prefer a different scope.