Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logs display wrong value when a Blocking Event Hook with response body changed #22026

Open
yrayegan opened this issue Mar 31, 2024 · 3 comments

Comments

@yrayegan
Copy link

Describe the Bug

When an event triggered by flow as a Blocking Event Hook with any Response Body for first time, a log created. Then change the response body to any value and save it, you see all return value converted to last response body value!

To Reproduce

  1. create a collection (blog)
  2. create a flow - Event Hook | type: blocking | scope: items.create | collection: blog | response body: for example "firstLog"
  3. create a first blog item
  4. check event log - Trigger > option > return:"firstLog"
  5. change the flow option now with different response body: now "secondLog"
  6. check log again, return:"secondLog" ???
  7. it doesn't matter how many events' log with any response body value created, return value of all created logs converted to last response body value!
Rec.0001.mp4

Directus Version

v10.10.4

Hosting Strategy

Self-Hosted (Docker Image)

@br41nslug
Copy link
Member

Looks like the Trigger Options are just showing the current trigger options not the state of the trigger when the Flow as run 🤔

@paescuj
Copy link
Member

paescuj commented Apr 2, 2024

Looks like the Trigger Options are just showing the current trigger options not the state of the trigger when the Flow as run 🤔

Yeah, trigger options are not part of revisions, so it always shows the current values.
Not sure whether we can / want to take action here. Perhaps show a corresponding notice?

@br41nslug
Copy link
Member

br41nslug commented Apr 2, 2024

Well it's displayed as being part of the log for that specific execution. So I think they either don't belong in the logs (as you can see the trigger settings in the flow too) or need to be persisted with the flow logs.

It makes very little sense to see the current settings when looking at a log from a year ago (the entire trigger may been updated/changed/repurposed in the meantime)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 📋 Backlog
Development

No branches or pull requests

3 participants