langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 03:55:25 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Feedback tracing #19264

New Issue
Closed
opened 2026-02-21 19:57:43 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 19:57:43 -05:00
Owner
Copy Link
Copy Source

Originally created by @DavideDelbianco on GitHub (Oct 14, 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.

I have an issue tracing the user feedback.

I have created a small chat UI and used the /messages APIs and I cannot correctly track like/dislike because I track 99% of the data from within the workflow, where the identifier is workflow_run_id and send everything to an Elasticsearch index.

Later I wanted to track user feedback and update traces in Langfuse / Elasticsearch.
For Langfuse there's no issue since the Dify message_id is the Langfuse trace_id.

For my Elasticsearch index, on the other hand, it's impossible to reconcile the datum because I would need to receive the same identifier I had access to, while in the workflow.... workflow_run_id alongside the message_id that generated the message.

Is it possible to add the workflow_run_id to the data returned by GET /messages ? or to expose in the Start node the message_id to correctly trace messages across multiple systems?

I've already tried providing a custom trace_id in the body of the POST /chat-messages but:

  • it will not be used as the message_id
  • it will not be exposed in the start node for tracing purposes
  • it will not be returned with the GET messages API

This a major tracing issue for me :(
It would be appreciated to send the workflow_run_id / custom trace_id in the message items returned from API
And to expose as sys.trace_id the custom value that can be sent by API otherwise tracing is incomplete.

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 @DavideDelbianco on GitHub (Oct 14, 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/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. I have an issue tracing the user feedback. I have created a small chat UI and used the /messages APIs and I cannot correctly track like/dislike because I track 99% of the data from within the workflow, where the identifier is `workflow_run_id` and send everything to an Elasticsearch index. Later I wanted to track user feedback and update traces in Langfuse / Elasticsearch. For Langfuse there's no issue since the Dify `message_id` is the Langfuse `trace_id`. For my Elasticsearch index, on the other hand, it's impossible to reconcile the datum because I would need to receive the same identifier I had access to, while in the workflow.... `workflow_run_id` alongside the `message_id` that generated the message. Is it possible to add the workflow_run_id to the data returned by GET /messages ? or to expose in the Start node the message_id to correctly trace messages across multiple systems? I've already tried providing a custom `trace_id` in the body of the POST /chat-messages but: - it will not be used as the `message_id` - it will not be exposed in the start node for tracing purposes - it will not be returned with the GET messages API This a major tracing issue for me :( It would be appreciated to send the `workflow_run_id` / custom `trace_id` in the message items returned from API And to expose as sys.trace_id the custom value that can be sent by API otherwise tracing is incomplete. ### 2. Additional context or comments _No response_ ### 3. Can you help us with this feature? - [ ] I am interested in contributing to this feature.
yindo added the 💪 enhancement🌊 feat:workflow labels 2026-02-21 19:57:43 -05:00
yindo closed this issue 2026-02-21 19:57:43 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🌊 feat:workflow 💪 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#19264
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?