It’s taking 10-25 seconds to finish all workflow actions when I schedule an api workflow as opposed to finishing almost instantly without the one action that schedules the api workflow. Is this consistent with what other people are seeing? To test it, I removed all conditions from the schedule workflow action and just ran it with and without the schedule api workflow action.
Do you have parameters that you’re sending to the API Endpoint that require big searches?
1 Like
I don’t have any parameters that require searches.
Hi @romanmg and @dserber (also pingning @neerja here as she’s familiar with this work),
@dserber, your post doesn’t note whether you feel like this is new behavior, but I get the impression that you’re noting something that is now different from how it worked before.
Note that, a couple of weeks ago, a bug with Schedule API Workflow was fixed. It turns out that “Schedule API Workflow” was broken for quite a while. The way it was broken is that it was not reporting its return value properly on the client (browser) side.
(Schedule API Workflow returns a value representing the ID of the scheduled workflow so that this workflow can be canceled if desired/needed. Alternatively, checking that that value exists in an “Only when…” condition is a way of making subsequent workflow steps wait until the schedule action is truly complete before they execute.)
For quite some time, SAPIW was broken: It would always immediately report that it had finished (on the client side), always return a “null” value, and subsequent workflow steps would always just charge ahead.
That behavior was fine, except if one needed to ensure that the workflow actually got scheduled or if one really needed to get the ID of the scheduled workflow.
The proper function of SAPIW on the client side was restored via a bug fix pushed just short of a month ago.
SO, if one does not have downstream workflow steps that depend on the return value from SAPIW (or have steps like a “pause” step to enforce synchronous execution) one would expect that subsequent workflow actions would NOT wait for SAPIW to confirm scheduling before they execute…
But it’s possible that the way this works now, SAPIW may always kind of block downstream actions until its scheduling action is finished. If so, that would probably be a bug.
(The reason I’ve included @neerja here is to point this out, AND, to ensure that the Bubble team doesn’t “fix” this by breaking SAPIW again in the same way that it was broken before. As I note in the link below, I believe the original bug – the bad behavior of SAPIW – was introduced as a “performance enhancement”. But it’s actually essential that one be able to grab the return value of Schedule API Workflow for many use cases.)
I described the issue that lead me to discover this bug in the following thread. I’ve linked to my final post there which confirms the previous bad behavior of SAPIW is fixed, but note that it’s possible that the fix may have performance implications.
@dserber here are a couple of things you should check:
-
If you don’t need the return value of your Schedule API Workflow step, make sure that you don’t have subsequent workflow actions that check for “Results of Step x” (where x is the SAPIW step).
-
Ensure you don’t have a pause step or other synchronizing trick after SAPIW. (If neither 1 nor 2 is present, we should see the “asynchronous” behavior of SAPIW and subsequent workflow steps should not be waiting on SAPIW to finish before they start executing.)
-
Another thing to try might be to move the SAPIW into its own Custom Event and trigger that event rather than having the SAPIW step in your workflow where it is now.
Aside from what I describe above, it does seem to me that “10 - 20 seconds” would be a long time for SAPIW to complete its scheduling. Is your app often at capacity? (As @romanmg points out, if the parameters being sent to SAPIW are complex, that might also explain the delay. But in general, I feel like you shouldn’t be seeing it delay quite that long. And, as I note above, we should be able to make SAPIW behave in the “old” way as long as we don’t have some sort of downstream dependency on its return value.)
It’s entirely possible that SAPIW is still not quite working right in that it always creates a delay, even when it should not. (And again that would be a bug, but @Bubble should not fix that bug by making SAPIW misbehave.)
1 Like
@keith noted
@dserber there can be a number of factors impacting workflow performance that are not bugs. If you are suddenly seeing a drop in performance, try to identify recent changes to your app, spikes in capacity usage, and once you have eliminated those, please submit a bug report.
1 Like
@neerja (and others on this thread), I did some quick checking and I’m pretty sure that
SAPIW behaves as it should. If one does not have downstream dependencies, downstream actions do not wait. If one does have downstream dependencies, those actions do wait (that is, they do not execute until SAPIW has successfully scheduled the workflow action).
(This is one of those things that’s actually sort of a pain to test. So I’ve not made a simple example that proves absolutely that behavior is as expected. I’m just noting that based on what my live app does it appears to be working correctly. Workflows that are otherwise identical – except for whether they wait for the return value from SAPIW or not – take different times to complete. Ones that don’t wait are faster. Ones that do wait are slower. As expected.)
This is a long way of saying that @dserber’s issue is either (1) because they actually do have downstream dependencies on the return value from SAPIW (and are just now realizing that this will result in delays, unlike when SAPIW was broken) or (2) their app is capacity limited and so that action is taking an inordinately long time to complete. (And, of course, both (1) and (2) may be going on as these are not mutually exclusive issues!)
2 Likes