mirror of
https://github.com/langgenius/dify-official-plugins.git
synced 2026-07-21 17:45:23 -04:00
Add finish_reason to the Bedrock plugin #620
Reference in New Issue
Block a user
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?
Originally created by @yosse95ai on GitHub (Sep 4, 2025).
Self Checks
1. Is this request related to a challenge you're experiencing? Tell me about your story.
I want to use a loop node to repeat the generation of text as long as the finish_reason is max_token, but the output of the Bedrock plugin does not include the finish_reason. The only output I can receive at the next node is text. Is this bag?
2. Additional context or comments
My Bedrock plugin is v0.0.34 now.
On the other hand, the Claude 3.5 Sonnet output itself contains a finish_reason. We need a way to reference this in the next node.
3. Can you help us with this feature?
@yosse95ai commented on GitHub (Sep 7, 2025):
This issue is related https://github.com/langgenius/dify-official-plugins/issues/1450
@dosubot[bot] commented on GitHub (Sep 23, 2025):
Hi, @yosse95ai. I'm Dosu, and I'm helping the dify-official-plugins team manage their backlog and am marking this issue as stale.
Issue Summary:
Next Steps:
Thank you for your understanding and contribution!
@yosse95ai commented on GitHub (Sep 23, 2025):
This is still the case in the latest version.
@dosubot[bot] commented on GitHub (Sep 23, 2025):
@crazywoola The user confirms that the issue with adding the "finish_reason" field to the Bedrock plugin's output is still present in the latest version and needs attention. Could you please assist with this?
@yosse95ai commented on GitHub (Nov 26, 2025):
@dosu I'd like you to fix this bug.
@dosubot[bot] commented on GitHub (Nov 26, 2025):
The Bedrock plugin doesn't output
finish_reasonbecause it's not included in the final result object, even though the Bedrock API provides it in both synchronous and streaming responses. To fix this, the plugin code should be updated so that the_handle_converse_responsemethod attachesfinish_reasonfrom the API response to the output object (LLMResult), just like it's done for streaming chunks in_handle_converse_stream_responsesee code reference.If you want to contribute a fix, you’d need to:
stopReasonfrom the API response.finish_reasonfield to the output object so it’s available for downstream workflow nodes.This change would make the Bedrock plugin consistent with other plugins like Claude 3.5 Sonnet and enable loop control based on
finish_reason. There’s no workaround in the current release, so a code update is needed for this feature.To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@yosse95ai commented on GitHub (Nov 26, 2025):
@dosu Is it possible to reopen this issue and ask other contributors to make the fix?
@dosubot[bot] commented on GitHub (Nov 26, 2025):
Yes, it’s possible to request that an issue be reopened and ask contributors to make the fix. In this repository, users have previously commented on closed issues to explain the ongoing need and request that maintainers reopen them. Maintainers or users with the right permissions can then reopen the issue and invite contributors to help. Tagging relevant maintainers or contributors in your comment can help get attention and increase the chances of the issue being addressed. You can see an example of this process in action here: example thread.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@yosse95ai commented on GitHub (Nov 26, 2025):
@dosu Sorry, I don't have permission to reopen it. I can't press the button.
@dosubot[bot] commented on GitHub (Nov 26, 2025):
You’re right—only maintainers or users with special permissions can reopen issues on GitHub. The best way forward is to comment on the closed issue (#1450), clearly explaining that the bug is still present in the latest version and why it’s important to fix. Tagging maintainers (like @crazywoola) in your comment can help get their attention and increase the chances of the issue being reopened and prioritized. Here’s a template you can use:
Once you comment, keep an eye on the thread for any updates or requests for more info.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@dosubot[bot] commented on GitHub (Nov 26, 2025):
@crazywoola The user yosse95ai mentioned they don't have permission to reopen the issue and still need help with it. Could you please assist with this?
@yosse95ai commented on GitHub (Dec 17, 2025):
@dosu @crazywoola I want to get the finish_reason from Bedrock node.
@dosubot[bot] commented on GitHub (Dec 17, 2025):
The Bedrock plugin does not currently expose
finish_reasonin its output, even though the API provides it. The code reads the API'sstopReasonfield but does not attach it to the final result object, so downstream nodes can't access it for workflow control. To fix this, the_handle_converse_responsemethod should be updated to extractstopReasonfrom the response and add it as afinish_reasonfield in the returnedLLMResultobject—just like the streaming path already does for chunk deltas. There’s no workaround until this change is made, so a code update is required to enable this feature for workflow nodes. You can see the relevant code and technical details here.To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other