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.
As you point out, the backend workflow will trigger immediately as soon as the workflow begins.
So the fact that the backend workflow is being triggered before steps 1 and 2 complete is exactly what would be expected here…
If you want it to happen afterwards, you can either break the workflow up into custom events, or force it to wait by adding some reference to the result of the first two steps in the final step.
Yes and as per this thread Tip: Order of Operation - #2 by aschofer, We should place backend workflows in a custom event wherein it’s the last step of operation.
We have also tried splitting the workflow in to 2 specific custom events
1st custom event:
steps 1 and 2 above
2nd custom event:
schedule backend workflow
yet it still produces the same result—the backend WF still triggers first
@adamhholmes We tried to implement what you suggested and again, it still triggers the backend workflow first even after placing it in a different custom event:
By the time it reaches the 1st custom event (steps 1 and 2 above) the parent data type has already been deleted.
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 is a plugin that enables us to connect with our external Wasabi S3 buckets.
As for the context.async, how do we check if the plugin has that code in it? I appreciate the different assumption—I learn something new everyday in the forum!
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.
@ntabs
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?
My experience is that you can’t trust the debugger unless it’s a very basic workflow. Logs are a bit better. At some point you just setup your own logging hack/system.
