langgenius/dify-official-plugins
1
0
Fork 0
mirror of https://github.com/langgenius/dify-official-plugins.git synced 2026-07-21 17:45:23 -04:00
Code Issues 54 Packages Projects Releases Wiki Activity

[PR #2208] [MERGED] Feat/add request id for tongyi error message #2324

New Issue
Closed
opened 2026-02-16 11:16:41 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 11:16:41 -05:00
Owner
Copy Link
Copy Source

📋 Pull Request Information

Original PR: https://github.com/langgenius/dify-official-plugins/pull/2208
Author: @scdeng
Created: 12/8/2025
Status: ✅ Merged
Merged: 12/9/2025
Merged by: @crazywoola

Base: main ← Head: feat/add-request-id-for-tongyi

📝 Commits (3)

  • ca587a5 Add request_id to the exception message when the Tongyi model fails.
  • 4878fc7 Append request_id to the exception message when the Tongyi model fails.
  • d5c3760 Apply suggestion from @gemini-code-assist[bot]

📊 Changes

2 files changed (+18 additions, -5 deletions)

View changed files

📝 models/tongyi/manifest.yaml (+1 -1)
📝 models/tongyi/models/llm/llm.py (+17 -4)

📄 Description

Summary

This PR improves error handling in TongyiLargeLanguageModel by adding support for including an optional request_id from the Tongyi API response in exception messages.

What Changed

  1. Enhanced _handle_error_response

    • Added an optional request_id parameter to capture the unique request ID from Tongyi API responses.
    • Modified error message formatting to append request_id if available, without altering the original behavior when request_id is absent.

  2. Updated _handle_generate_response (non-streaming)

    • Previously did not pass the model parameter when invoking _handle_error_response, resulting in error messages that only contained the message text without the model name or status code.
    • Now passes the model parameter, ensuring error messages consistently include the model name, status code, and message across both streaming and non-streaming scenarios.
    • This change improves error consistency and makes logs easier to interpret without requiring additional context lookup.

  3. Updated _handle_generate_stream_response (streaming)

    • Modified error handling to extract and pass both model and request_id when API calls fail, aligning with the enhancement in non-streaming.
    • Guarantees that streaming errors contain the same level of context as non-streaming errors, including the unique request_id for correlation with server logs.

  4. Consistency Improvements

    • Both streaming and non-streaming error handling paths now:
      • Include model in error messages.
      • Append request_id when provided.
      • Maintain backward compatibility if these values are not available.

Benefits

  • Tongyi's error codes are broad categories that can represent multiple specific issues. A single error code maps to a large set of possible root causes. When a specific problem occurs, the request_id is essential for the Tongyi service team to look up the exact request and diagnose the true cause. request_id really Speeds up issue resolution by allowing maintainers and the Tongyi support team to correlate client errors directly with server-side logs for the exact failing request.
  • Backwards compatible: if request_id is not present, behavior remains unchanged.
  • No impact on successful API calls.

Related Issues or Context

This PR contains Changes to Non-Plugin

  • Documentation
  • Other

This PR contains Changes to Non-LLM Models Plugin

  • I have Run Comprehensive Tests Relevant to My Changes

This PR contains Changes to LLM Models Plugin

  • My Changes Affect Message Flow Handling (System Messages and User→Assistant Turn-Taking)
  • My Changes Affect Tool Interaction Flow (Multi-Round Usage and Output Handling, for both Agent App and Agent Node)
  • My Changes Affect Multimodal Input Handling (Images, PDFs, Audio, Video, etc.)
  • My Changes Affect Multimodal Output Generation (Images, Audio, Video, etc.)
  • My Changes Affect Structured Output Format (JSON, XML, etc.)
  • My Changes Affect Token Consumption Metrics
  • My Changes Affect Other LLM Functionalities (Reasoning Process, Grounding, Prompt Caching, etc.)
  • Other Changes (Add New Models, Fix Model Parameters etc.)

Version Control (Any Changes to the Plugin Will Require Bumping the Version)

  • I have Bumped Up the Version in Manifest.yaml (Top-Level Version Field, Not in Meta Section)

Dify Plugin SDK Version

  • I have Ensured dify_plugin>=0.3.0,<0.6.0 is in requirements.txt (SDK docs)

Environment Verification (If Any Code Changes)

Local Deployment Environment

  • Dify Version is: , I have Tested My Changes on Local Deployment Dify with a Clean Environment That Matches the Production Configuration.

SaaS Environment

  • I have Tested My Changes on cloud.dify.ai with a Clean Environment That Matches the Production Configuration

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/langgenius/dify-official-plugins/pull/2208 **Author:** [@scdeng](https://github.com/scdeng) **Created:** 12/8/2025 **Status:** ✅ Merged **Merged:** 12/9/2025 **Merged by:** [@crazywoola](https://github.com/crazywoola) **Base:** `main` ← **Head:** `feat/add-request-id-for-tongyi` --- ### 📝 Commits (3) - [`ca587a5`](https://github.com/langgenius/dify-official-plugins/commit/ca587a5b93cfed0bc671519acd39644e3e2c25c8) Add request_id to the exception message when the Tongyi model fails. - [`4878fc7`](https://github.com/langgenius/dify-official-plugins/commit/4878fc7c61bcd719e36a98c5d5c8611e29650444) Append request_id to the exception message when the Tongyi model fails. - [`d5c3760`](https://github.com/langgenius/dify-official-plugins/commit/d5c3760305e005d0ed170f1e98c3b8dd8defc076) Apply suggestion from @gemini-code-assist[bot] ### 📊 Changes **2 files changed** (+18 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `models/tongyi/manifest.yaml` (+1 -1) 📝 `models/tongyi/models/llm/llm.py` (+17 -4) </details> ### 📄 Description ## Summary This PR improves error handling in `TongyiLargeLanguageModel` by adding support for including an optional `request_id` from the Tongyi API response in exception messages. ## What Changed 1. **Enhanced `_handle_error_response`** - Added an optional `request_id` parameter to capture the unique request ID from Tongyi API responses. - Modified error message formatting to append `request_id` if available, without altering the original behavior when `request_id` is absent. 2. **Updated `_handle_generate_response` (non-streaming)** - Previously did **not** pass the `model` parameter when invoking `_handle_error_response`, resulting in error messages that only contained the `message` text without the model name or status code. - Now passes the `model` parameter, ensuring error messages consistently include the model name, status code, and message across both streaming and non-streaming scenarios. - This change improves error consistency and makes logs easier to interpret without requiring additional context lookup. 3. **Updated `_handle_generate_stream_response` (streaming)** - Modified error handling to extract and pass both `model` and `request_id` when API calls fail, aligning with the enhancement in non-streaming. - Guarantees that streaming errors contain the same level of context as non-streaming errors, including the unique `request_id` for correlation with server logs. 4. **Consistency Improvements** - Both streaming and non-streaming error handling paths now: - Include `model` in error messages. - Append `request_id` when provided. - Maintain backward compatibility if these values are not available. ## Benefits - Tongyi's error codes are broad categories that can represent multiple specific issues. A single error code maps to a large set of possible root causes. When a specific problem occurs, the `request_id` is essential for the Tongyi service team to look up the exact request and diagnose the true cause. request_id really Speeds up issue resolution by allowing maintainers and the Tongyi support team to correlate client errors directly with server-side logs for the exact failing request. - Backwards compatible: if `request_id` is not present, behavior remains unchanged. - No impact on successful API calls. ## Related Issues or Context <!-- ⚠️ NOTE: This repository is for Dify Official Plugins only. For community contributions, please submit to https://github.com/langgenius/dify-plugins instead. - Link Related Issues if Applicable: #1976 - Or Provide Context about Why this Change is Needed --> ## This PR contains Changes to *Non-Plugin* <!-- Put an `x` in all the boxes that apply by replacing [ ] with [x] For example: - [x] Documentation --> - [ ] Documentation - [ ] Other ## This PR contains Changes to *Non-LLM Models Plugin* - [ ] I have Run Comprehensive Tests Relevant to My Changes <!-- 📷 Include Screenshots/Videos Demonstrating the Fix, New Feature, or the Behavior Before/After Breaking Changes. --> ## This PR contains Changes to *LLM Models Plugin* <!-- LLM Models Test Example: --> <!-- https://github.com/langgenius/dify-official-plugins/blob/main/.assets/test-examples/llm-plugin-tests/llm_test_example.md --> - [ ] My Changes Affect Message Flow Handling (System Messages and User→Assistant Turn-Taking) <!-- 📷 Include Screenshots/Videos Demonstrating the Fix, New Feature, or the Behavior Before/After Breaking Changes. --> - [ ] My Changes Affect Tool Interaction Flow (Multi-Round Usage and Output Handling, for both Agent App and Agent Node) <!-- 📷 Include Screenshots/Videos Demonstrating the Fix, New Feature, or the Behavior Before/After Breaking Changes. --> - [ ] My Changes Affect Multimodal Input Handling (Images, PDFs, Audio, Video, etc.) <!-- 📷 Include Screenshots/Videos Demonstrating the Fix, New Feature, or the Behavior Before/After Breaking Changes. --> - [ ] My Changes Affect Multimodal Output Generation (Images, Audio, Video, etc.) <!-- 📷 Include Screenshots/Videos Demonstrating the Fix, New Feature, or the Behavior Before/After Breaking Changes. --> - [ ] My Changes Affect Structured Output Format (JSON, XML, etc.) <!-- 📷 Include Screenshots/Videos Demonstrating the Fix, New Feature, or the Behavior Before/After Breaking Changes. --> - [ ] My Changes Affect Token Consumption Metrics <!-- 📷 Include Screenshots/Videos Demonstrating the Fix, New Feature, or the Behavior Before/After Breaking Changes. --> - [ ] My Changes Affect Other LLM Functionalities (Reasoning Process, Grounding, Prompt Caching, etc.) <!-- 📷 Include Screenshots/Videos Demonstrating the Fix, New Feature, or the Behavior Before/After Breaking Changes. --> - [x] Other Changes (Add New Models, Fix Model Parameters etc.) <!-- 📷 Include Screenshots/Videos Demonstrating the Fix, New Feature, or the Behavior Before/After Breaking Changes. --> ## Version Control (Any Changes to the Plugin Will Require Bumping the Version) - [x] I have Bumped Up the Version in Manifest.yaml (Top-Level `Version` Field, Not in Meta Section) <!-- ⚠️ NOTE: Version Format: MAJOR.MINOR.PATCH - MAJOR (0.x.x): Reserved for Significant architectural changes or incompatible API modifications - MINOR (x.0.x): For New feature additions while maintaining backward compatibility - PATCH (x.x.0): For Backward-compatible bug fixes and minor improvements - Note: Each Version Component (MAJOR, MINOR, PATCH) Can Be 2 Digits, e.g., 10.11.22 --> ## Dify Plugin SDK Version - [x] I have Ensured `dify_plugin>=0.3.0,<0.6.0` is in requirements.txt ([SDK docs](https://github.com/langgenius/dify-plugin-sdks/blob/main/python/README.md)) ## Environment Verification (If Any Code Changes) <!-- ⚠️ NOTE: At Least One Environment Must Be Tested. --> ### Local Deployment Environment - [x] Dify Version is: <!-- Specify Your Version (e.g., 1.10.1) -->, I have Tested My Changes on Local Deployment Dify with a Clean Environment That Matches the Production Configuration. <!-- - Python Virtual Env Matching Manifest.yaml & requirements.txt - No Breaking Changes in Dify That May Affect the Testing Result --> ### SaaS Environment - [ ] I have Tested My Changes on cloud.dify.ai with a Clean Environment That Matches the Production Configuration <!-- - Python Virtual Env Matching Manifest.yaml & requirements.txt --> --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
yindo added the pull-request label 2026-02-16 11:16:41 -05:00
yindo closed this issue 2026-02-16 11:16:41 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
bug
bug
dependencies
documentation
enhancement
good first issue
invalid
pull-request
Mirrored from GitHub Pull Request
 question
stale
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify-official-plugins#2324
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?