Is there a way to return a response without aborting the workflow?

pachocastillosr

Hi,

I am connecting Bubble with Xano and using Xano for long workflows (some take hours to complete).

The problem is that Bubble expects a response within a few minutes of making the call to Xano or it will timeout. So I was thinking I could send a "workflow initiated" response to Bubble as soon as the call to Xano is made (to avoid Bubble's timeout) and then send the actual response of the workflow as a POST to one of my Bubble app's endpoint.

Is there a way that I can send this instant "workflow initiated" response without terminating the workflow in Xano?

Thanks!

Ray Deck

The crux is that Xano endpoints do not support streaming output, in which an inital payload is returned before sending more data. It will only reply to bubble once.

If you want immediate, asynchronous invocation, I recommend using a second endpoint. Bubble calls endpoint A. ENdpoint A calls endpoint B and returns without waiting for it to reply. Endpoint B calls a webhook on Bubble notifying it that the job is done.

Pawel Magdanski

hi,

If a task get's hours to complete I would suggest to do it in background tasks and then send the results to frontend via regular endpoint.

Ray Deck

Building on @Pawel Magdanski's idea, you can have bubble fire a request into xano that xano adds to a queue of tasks it will manage via background tasks. This API-to-task workflow is relatively common and straightforward. The API adds the info to a table, and then the background task is running every x minutes or what have you to check the table for jobs it should do.

pachocastillosr

Thanks for replying! @Pawel Magdanski @Ray Deck

The feature I've built is the following: A user of my Bubble app clicks a button, Bubble calls Xano, Xano calls some external databases and process some data (this may take hours depending on the amount of data), Xano calls Bubble returning the resulting data.

This will not be run automatically at a certain time nor be repeated at a certain time, just when the user clicks the button in my Bubble app. It also requieres some strings as input (according to Xano's docs, background tasks don't take inputs).

Taking this into account, would it be better to run it as a background task instead of regular api function stack? Why?

pachocastillosr

@Ray Deck that worked for me thanks! My only concern now is that Xano timeout my workflows, since they are long.

I could be running multiple of this long workflows simultaneously (one for each user that clicks the button in Bubble), do you think I can get problems in Xano because of lots of this long workflows running simultaneously as regular api workflows (not backend tasks)?

Ray Deck

Yes that can cause a problem depending on how many simultaneous processes you have going, and how intensive they are. In those cases moving to a batch process to queue and sequence the requests - along the lines of what we discussed with @Pawel Magdanski in the previous segment - will address that crowding at the price of losing a bit of responsiveness (because the second process will have to wait in line or for the next task invocation) and adding a bit of complexity for setting up this time bridge.

pachocastillosr

What limits the amount of processes running simultaneously in Xano? Is it something like "cpu usage" or "capacity". Is there a dashboard or somewhere where I can see how much of that "capacity" am I using?

Taking into account that my Xano workflows requiere some string inputs that come from Bubble and according to Xano's docs, background tasks don't take inputs, then I'd have to build that queue system without using any background tasks. In fact, I wouldn't use background tasks at all, right?

So what I'd have to do is queue the calls to the regular Xano api endpoint that does the intensive workflows so that I don't surpass the "cpu or capacity usage limitations"? Please let me know if I'm not understanding correctly. Thanks @Ray Deck !

Ray Deck

What I would do - and have done - in this situation is implement a queuing system. I have the endpoint write to a database table and then return. A background task that runs at some frequent period polls the database table for information in a "not yet processed" state. Then it processes that data and updates the table record to "processed".

So that's how you bridge the inputs from your endpoint to the background task over time. No need to throttle the endpoint.

pachocastillosr

Got it!

So how can I know when the background task is running too frequently and therefore throttling the endpoint?

Is there somewhere where I can see/measure this "endpoint available capacity" usage? @Ray Deck

Ray Deck

You can see the number of API requests run in a time period on your workspace, and the instance view will show windowed average CPU utilization on the machine.

But memory is more often constraining than CPU for parallel processes with high i/o or network wait. And Xano doesn't have great observability on that front. So AFAIK you will be fiddling a bit in the dark until that changes.

pachocastillosr

Thanks for all the helpful insights @Ray Deck ! One last question, where can I access this instance view to see the average CPU utilization? I can't find that

Ray Deck

Go up to your instance in your paid plan - its where you select the workspace you want to be in. There you will see a stacked line chart of your CPU utilization broken down by used by the web service and the database. It's not very complete, but a start!

pachocastillosr

Hi @Ray Deck , I have one question regarding your response:

" If you want immediate, asynchronous invocation, I recommend using a second endpoint. Bubble calls endpoint A. ENdpoint A calls endpoint B and returns without waiting for it to reply. Endpoint B calls a webhook on Bubble notifying it that the job is done."

When Bubble calls endpoint A, I assign a "pending" status to the process in Bubble's front end, so that the user knows that the job is "in process".

If endpoint B fails for any reason (like an external api call error), is there a way that I can post the error message thrown by endpoint B to Bubble, so that I can notify the user that endpoint B stopped running? Otherwise the job will stay "in process" forever in the front end.


Thanks!

Ray Deck

Sure, you could have endpoint B be responsible for updating that status based on what it sees along the way. If it has a fatal error, you might not get a notice, so you might back it up with a background task that looks at aged-out processes and marks them as error or timeout.

pachocastillosr

@Ray Deck got it, thanks!

pachocastillosr

Hi @Ray Deck, I hope you are doing well.

One quick question:
Is there a way to cancel the process running in endpoint B by clicking a button in Bubble? How?
Is there a way to cancel a workflow that is running on a Xano endpoint at all?

Thanks!

Ray Deck

The way I woudl go about this is to choose a redis key to identify whether this process should cancel. Like call it "shouldCancel". Then you have your process get the value at this key frequently thorugh its stack, and if it sees the value as true, it returns/preconditions out.

Then you make an endpoint to cancel your process that bubble can call. The endpoint just sets the shouldCancel value to true.

Those combined show how to use redis for high-performance interprocess communication. Pretty useful!

pachocastillosr

@Ray Deck great solution, thanks!