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

Include request_id in _handle_error_response of TongyiLargeLanguageModel for better error traceability #766

New Issue
Closed
opened 2026-02-16 10:20:27 -05:00 by yindo · 4 comments
yindo commented 2026-02-16 10:20:27 -05:00
Owner
Copy Link
Copy Source

Originally created by @scdeng on GitHub (Oct 30, 2025).

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.

Currently, the _handle_error_response function does not have any parameter or logic to include the request_id from the originating request/response. This makes it harder to trace the exact request that caused the error when reviewing logs or diagnosing API issues.

For example, in the calling code:

for index, response in enumerate(responses):
    if response.status_code not in {200, HTTPStatus.OK}:
        self._handle_error_response(response.status_code, response.message, model)

The response to object (GenerationResponse which is import from from dashscope.api_entities.dashscope_response) has a request_id field, but it is not passed to _handle_error_response.

Proposed Enhancement
Add a new optional request_id parameter to _handle_error_response and append it to the error message when present. This will allow developers/operators to quickly find the problematic request in logs or tracing systems.

Example usage:

python

self._handle_error_response(
    status_code=response.status_code,
    message=response.message,
    model=model,
    request_id=response.request_id
)

Inside _handle_error_response:

python
error_msg = f"[Request ID: {request_id}] " + error_msg if request_id else error_msg
Benefits
Easier debugging and log correlation
Minimal impact on existing code (parameter is optional)
Aligns with general observability best practices

2. Additional context or comments

No response

3. Can you help us with this feature?

  • I am interested in contributing to this feature.
Originally created by @scdeng on GitHub (Oct 30, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify-official-plugins/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 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. Currently, the _handle_error_response function does not have any parameter or logic to include the request_id from the originating request/response. This makes it harder to trace the exact request that caused the error when reviewing logs or diagnosing API issues. For example, in the calling code: ``` for index, response in enumerate(responses): if response.status_code not in {200, HTTPStatus.OK}: self._handle_error_response(response.status_code, response.message, model) ``` The response to object (GenerationResponse which is import from from dashscope.api_entities.dashscope_response) has a request_id field, but it is not passed to _handle_error_response. **Proposed Enhancement** Add a new optional request_id parameter to _handle_error_response and append it to the error message when present. This will allow developers/operators to quickly find the problematic request in logs or tracing systems. Example usage: python ``` self._handle_error_response( status_code=response.status_code, message=response.message, model=model, request_id=response.request_id ) ``` Inside _handle_error_response: python `error_msg = f"[Request ID: {request_id}] " + error_msg if request_id else error_msg ` **Benefits** Easier debugging and log correlation Minimal impact on existing code (parameter is optional) Aligns with general observability best practices ### 2. Additional context or comments _No response_ ### 3. Can you help us with this feature? - [x] I am interested in contributing to this feature.
yindo added the enhancement label 2026-02-16 10:20:27 -05:00
yindo closed this issue 2026-02-16 10:20:27 -05:00
yindo commented 2026-02-16 10:20:27 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Nov 15, 2025):

Hi, @scdeng. I'm Dosu, and I'm helping the dify-official-plugins team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You suggested enhancing the _handle_error_response function in TongyiLargeLanguageModel by adding an optional request_id parameter to improve error message traceability.
  • This change aims to make debugging and log correlation easier without impacting existing functionality.
  • You expressed willingness to contribute the implementation.
  • There has been no further activity or discussion on this issue since it was opened.

Next Steps:

  • Please let me know if this enhancement is still relevant for the latest version of dify-official-plugins by commenting on this issue.
  • If I do not hear back within 5 days, I will automatically close the issue.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Nov 15, 2025): Hi, @scdeng. I'm [Dosu](https://dosu.dev), and I'm helping the dify-official-plugins team manage their backlog and am marking this issue as stale. **Issue Summary:** - You suggested enhancing the `_handle_error_response` function in `TongyiLargeLanguageModel` by adding an optional `request_id` parameter to improve error message traceability. - This change aims to make debugging and log correlation easier without impacting existing functionality. - You expressed willingness to contribute the implementation. - There has been no further activity or discussion on this issue since it was opened. **Next Steps:** - Please let me know if this enhancement is still relevant for the latest version of dify-official-plugins by commenting on this issue. - If I do not hear back within 5 days, I will automatically close the issue. Thank you for your understanding and contribution!
yindo commented 2026-02-16 10:20:27 -05:00
Author
Owner
Copy Link
Copy Source

@scdeng commented on GitHub (Dec 8, 2025):

Hi @dosubot,

Thanks for the follow-up and for keeping the backlog organized.
Yes, this enhancement is still relevant. I’m currently preparing the code changes to add the optional request_id parameter to the _handle_error_response function in TongyiLargeLanguageModel to improve error traceability.

I’m happy to contribute the implementation and will submit a PR once it’s ready.
Since the issue has not yet been resolved, could you please reopen it so we can track progress and link the upcoming PR?

Thank you!

@scdeng commented on GitHub (Dec 8, 2025): Hi @dosubot, Thanks for the follow-up and for keeping the backlog organized. Yes, this enhancement is still relevant. I’m currently preparing the code changes to add the optional request_id parameter to the _handle_error_response function in TongyiLargeLanguageModel to improve error traceability. I’m happy to contribute the implementation and will submit a PR once it’s ready. Since the issue has not yet been resolved, could you please reopen it so we can track progress and link the upcoming PR? Thank you!
yindo commented 2026-02-16 10:20:27 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 8, 2025):

@crazywoola The user scdeng has indicated that the enhancement to add an optional request_id parameter to the _handle_error_response function in TongyiLargeLanguageModel is still relevant and they are preparing a PR for it. Could you please reopen the issue to track progress and link the upcoming PR?

@dosubot[bot] commented on GitHub (Dec 8, 2025): @crazywoola The user scdeng has indicated that the enhancement to add an optional request_id parameter to the _handle_error_response function in TongyiLargeLanguageModel is still relevant and they are preparing a PR for it. Could you please reopen the issue to track progress and link the upcoming PR?
yindo commented 2026-02-16 10:20:27 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 8, 2025):

Hi @scdeng! I'm Dosu and I’m helping the dify-official-plugins team.

Thanks for confirming the enhancement is still needed and for preparing the PR! Issue reopening is usually handled by maintainers, but you can reference the original issue in your PR description to keep everything linked and traceable.

Your approach—adding an optional request_id parameter to _handle_error_response and including it in error messages—fits well with recent improvements to error handling in TongyiLargeLanguageModel, and there are no conflicting changes in the repo so far (see recent PR #1636).

When you submit your PR, include a clear description of the change and its benefits for error traceability. If you run into any questions or need help with the contribution process, let me know!

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Dec 8, 2025): <!-- Greeting --> Hi @scdeng! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify-official-plugins team. <!-- Answer --> Thanks for confirming the enhancement is still needed and for preparing the PR! Issue reopening is usually handled by maintainers, but you can reference the original issue in your PR description to keep everything linked and traceable. Your approach—adding an optional request_id parameter to _handle_error_response and including it in error messages—fits well with recent improvements to error handling in TongyiLargeLanguageModel, and there are no conflicting changes in the repo so far ([see recent PR #1636](https://github.com/langgenius/dify-official-plugins/pull/1636)). When you submit your PR, include a clear description of the change and its benefits for error traceability. If you run into any questions or need help with the contribution process, let me know! <!-- 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/c4600582-89cb-4ce2-8ed9-3290094af549?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/c4600582-89cb-4ce2-8ed9-3290094af549?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/c4600582-89cb-4ce2-8ed9-3290094af549?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/c4600582-89cb-4ce2-8ed9-3290094af549?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c4600582-89cb-4ce2-8ed9-3290094af549?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/c4600582-89cb-4ce2-8ed9-3290094af549?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c4600582-89cb-4ce2-8ed9-3290094af549?feedback_type=other)</sup> [![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=Thanks%20for%20confirming%20the%20enhancement%20is%20still%20needed%20and%20for%20preparing%20the%20PR%21%20Issue%20reopening%20is%20usually%20handled%20by%20maintainers%2C%20but%20you%20can%20reference%20the%20original%20issue%20in%20your%20PR%20description%20to%20keep%20everything%20linked%20and%20traceable.%20%0A%0AYour%20approach%E2%80%94adding%20an%20optional%20request_id%20parameter%20to%20_handle_error_response%20and%20including%20it%20in%20error%20messages%E2%80%94fits%20well%20with%20recent%20improvements%20to%20error%20handling%20in%20TongyiLargeLanguageModel%2C%20and%20there%20are%20no%20conflicting%20changes%20in%20the%20repo%20so%20far%20%28%5Bsee%20recent%20PR%20%231636%5D%28https%3A//github.com/langgenius/dify-official-plugins/pull/1636%29%29.%20%0A%0AWhen%20you%20submit%20your%20PR%2C%20include%20a%20clear%20description%20of%20the%20change%20and%20its%20benefits%20for%20error%20traceability.%20If%20you%20run%20into%20any%20questions%20or%20need%20help%20with%20the%20contribution%20process%2C%20let%20me%20know%21)&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/1976)
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 enhancement
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#766
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?