I wonder why I’m suddenly back at this again. Our workflows were working fine up until now
The order of operations within workflows has always been an issue especially with new Bubblers. We have been following these awesome tips by @aschofer in this thread for as long as we can remember Tip: Order of Operation Yet suddenly our workflows are suddenly not running in order.
For context, we’re deleting data using an API from a plugin in steps 1 and 2. The last step, step 3, deletes the parent data (the data source of steps 1 and 2) in a backend workflow
We all know that backend workflows trigger instantly in a workflow so we placed it inside a custom event, together with steps 1 and 2, where the backend workflow is in the last step. However, this seems to not work at all. The backend WF still triggers instantly, leaving steps 1 and 2 unperformed.
What it is the “delete files/folders wasabis3”?
Is there any async code inside it? Is the async code using context.async?
Maybe if there is async code but it’s not using context.async for wat concerns bubble the actions completes almost immediately, even though there is still code running in an async function, and will trigger the next action with the possibility of creating a rush condition.
It’s not necessarely the reason. You can ask the developer, or you can try to schedule the final delete more in the future so that you are sure nothing else is using the thing to be deleted.
Try to schedule it 10 minutes in the future, if you still have problems then it’s something else.
Stet-by-step debugger mode doesn’t allow you to execute and analyse each step separately in live mode. All backend WFs/steps shoot as soon as you trigger the main WF and what you see while jumping between steps in debugger is a result of what already happened:
This makes debugging WFs/actions that are deleting multiple things that are connected with each other complicated (especially, if you have some satellite or related Data Types).
What helped me to solve a problem similar to yours:
I’ve created custom states to store things-to-delete and wrapped them in a custom event that was placed first in my main WF. While deleting things in subsequent WFs/actions (also wrapped in custom events) I was referencing Things from custom states, not something from a group/rg/current page.
Checking the flow in Server Logs.
P.S. I my case I wasn’t dealing with API calls, so my suggestions above may not be helpful for your.
Hey @artemzheg, I appreciate the response. Thanks for helping out!
So I was testing out our workflows again without changing anything but this time, I did not use the step-by-step mode in the debugger. Just the normal and it suddenly works again
Here’s what I found out:
Plugin actions (or at least this specific plugin) tend to follow and wait for the order of operation in the step-by-step mode in the debugger while the database actions and API WFs don’t, hence the error where the plugin actions do not have something to reference to anymore since the data has already been deleted by the subsequent workflow actions.
Running it without the debugger seems to work just fine. Although I wonder why this is the case since the debugger should not have any effect whatsoever in the workflows…
If I got it right, this would be a big news for me, it definitely changes the way how I think about the debugger. Have you noticed this behavior in the past @dorilama@adamhholmes?