🐛 Tongyi LLM plugin incorrectly handles provider error responses #610

Closed
opened 2026-02-16 10:19:54 -05:00 by yindo · 1 comment
Owner

Originally created by @laipz8200 on GitHub (Sep 2, 2025).

Originally assigned to: @laipz8200 on GitHub.

Current Behavior:
The Tongyi LLM plugin currently treats all API error responses as regardless of the actual HTTP status code returned by the provider.

Expected Behavior:
Different HTTP status codes should be mapped to appropriate error types:

  • 400, 422: BadRequestError
  • 401, 403: AuthorizationError
  • 429: RateLimitError
  • 500+: ServerUnavailableError

Impact:
This affects proper error handling and user experience when using the Tongyi LLM plugin, as users cannot distinguish between different types of errors (authentication issues, rate limits, bad requests, etc.).

Environment:

  • Plugin: Tongyi LLM
  • Current Version: 0.0.43
Originally created by @laipz8200 on GitHub (Sep 2, 2025). Originally assigned to: @laipz8200 on GitHub. **Current Behavior:** The Tongyi LLM plugin currently treats all API error responses as regardless of the actual HTTP status code returned by the provider. **Expected Behavior:** Different HTTP status codes should be mapped to appropriate error types: - 400, 422: BadRequestError - 401, 403: AuthorizationError - 429: RateLimitError - 500+: ServerUnavailableError **Impact:** This affects proper error handling and user experience when using the Tongyi LLM plugin, as users cannot distinguish between different types of errors (authentication issues, rate limits, bad requests, etc.). **Environment:** - Plugin: Tongyi LLM - Current Version: 0.0.43
yindo added the bug label 2026-02-16 10:19:54 -05:00
yindo closed this issue 2026-02-16 10:19:54 -05:00
Author
Owner

@dosubot[bot] commented on GitHub (Sep 2, 2025):

You're right—currently, the Tongyi LLM plugin treats all provider error responses as ServiceUnavailableError, regardless of the actual HTTP status code. The error handling logic in the plugin's code raises ServiceUnavailableError for any non-200 response, without distinguishing between authentication, rate limit, bad request, or server errors. Although there's an _invoke_error_mapping property defined to map errors, it's not actually used in the main error handling flow, so error types aren't differentiated as expected see code reference.

To improve this, you could update the error handling in the _handle_generate_response and _handle_generate_stream_response methods to check the HTTP status code and raise the appropriate error type (e.g., BadRequestError for 400/422, AuthorizationError for 401/403, RateLimitError for 429, ServerUnavailableError for 500+). The spider plugin recently implemented a similar pattern for clearer error mapping, which could serve as a reference example.

Let me know if you want a sample code snippet for this!

To reply, just mention @dosu.


How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (Sep 2, 2025): <!-- Answer --> You're right—currently, the Tongyi LLM plugin treats all provider error responses as ServiceUnavailableError, regardless of the actual HTTP status code. The error handling logic in the plugin's code raises ServiceUnavailableError for any non-200 response, without distinguishing between authentication, rate limit, bad request, or server errors. Although there's an _invoke_error_mapping property defined to map errors, it's not actually used in the main error handling flow, so error types aren't differentiated as expected [see code reference](https://github.com/langgenius/dify-official-plugins/blob/3c99dded889a4f6b8ac75bb228aa07186cef1427/models/tongyi/models/llm/llm.py). To improve this, you could update the error handling in the _handle_generate_response and _handle_generate_stream_response methods to check the HTTP status code and raise the appropriate error type (e.g., BadRequestError for 400/422, AuthorizationError for 401/403, RateLimitError for 429, ServerUnavailableError for 500+). The spider plugin recently implemented a similar pattern for clearer error mapping, which could serve as a reference [example](https://github.com/langgenius/dify-official-plugins/pull/1380). Let me know if you want a sample code snippet for this! <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/b15c78f3-23f3-4594-995f-0aec239619f6?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/b15c78f3-23f3-4594-995f-0aec239619f6?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/b15c78f3-23f3-4594-995f-0aec239619f6?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/b15c78f3-23f3-4594-995f-0aec239619f6?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/b15c78f3-23f3-4594-995f-0aec239619f6?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/b15c78f3-23f3-4594-995f-0aec239619f6?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/b15c78f3-23f3-4594-995f-0aec239619f6?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify-official-plugins/issues/1634)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify-official-plugins#610