Giving the operator transparent feedback about background processing of queries, etc

During testing we have noticed that depending on the network speed it can become difficult for the operator to tell if the Tulip player is still running and doing something in the background or whether is just got stalled for whatever reason…

This is usually the case when a network query or request is still being processed.

I am wondering how other users here are handling these kind of cases… Personally I would love to see some kind of widget that one could put somewhere which would only spin if there is still stuff going on in the background.

Best we have come up with right now is just a “dump” spinner as a custom widget which basically just keeps spinning endlessly… but this only works for “in-between” steps where you are hopping on and off to get certain things done…

Hey @sebme -

Welcome to the community! This is a great idea. Id imagine you are talking primarily about step level and app level triggers? The triggers running on buttons will change the button to a loading icon while they run, but there isn’t a good way to visualize this for step triggers. Is that right?

I can picture a loading bar across the top of the step or something to indicate the step load state, or any currently running triggers. Similar to a web browser. Do you think this would do what your need?


Hi Pete,

not sure if this would need to be trigger specific… I could imagine a global “I am still busy with something” indicator would be more what we are looking for in our particular case.

Right now if there is still something being processed, the player sometimes just seems to be freezing until that activity is done with no direct visual indicator.

We use dedicate step for long request time (for POST) with GIF during the process time.

Yes, that has been our workaround now as well… except we have used a custom widget for this… but this only works for dedicated steps… not if there is some botton interaction by the operator going on at steps… hence the question about a rather global “busy” indicator of some sort.

1 Like

Curious if this would be something that should support all triggers, or is the primary need for connector functions that tend to take a long time?

I wrote a feature request for this, along with a feature request to allow connector functions to run asynchronously when they don’t have outputs.


No, it equally applies to the internal queries as well… at least if a lot of records need to be modified… and certainly the overall latency has an impact here as well.

I assume if the general response latency is in the range of a few ms it might be ok without any further visual indicator - in principle.

But right now I am experiencing north of 200-300 ms on almost any database request (internal or connector via Table API) no matter how basic (is this normal after all?).

Then it certainly becomes an issue.

About asynchronous, Tulip connector are often use to make some master data check in our ERP SAP) before post a update request. As connector actions run in sequence the more control we have the longer operator wait. Run connector function in // can reduce dramatically response time.

A query execution time in the ballpark of 300ms isn’t surprising. In the backend, Tables are referencing Postgres databases, and the table UI is simply a no-code interface for writing SQL queries for that table.

As tables expand, and the complexity of queries expands, the time to execute queries grows. We leverage a lot of indexing to improve query performance, but often this can’t be leveraged for more intricate queries. Network speed can absolutely impact query performance as well.

We can do a lot to expose the fact that these operations are running in the background. I will connect with our player and design teams to get their thoughts on the right approach for this. We could expose this to a widget, but I would love if it was something you didn’t even need to add, it was just native behavior we handled better.


Hi Pete,

yes having this as a native visualization directly in the player itself could also be a solution.

Not to hijack the initial discussion here, but regarding the query times… you start getting me worried. In my testing we are currently talking about a few tables with no more than a handful of records. No fancy aggregations going on there… just simple selects and sometimes a query which is supposed to return a single record with an aggregate to fetch the ID of the record returned…

And this would still be seeing between 200 and 300ms per request?

Hey @sebme -

Do you mind shooting me a direct message with a link to your table? Our engineering team can check it out. It sounds like the most common root cause of slowness for simple queries is network speed between the device running Player and the cloud. Sometimes we see cases where the underlying database is living on a US server, and the customer is in the EU, and that drives performance issues.

This could also be tied to your instance being a trial, which has less allocated resources than an a customer.

We can dig in!

Thank you, Pete. Looks like someone is already looking into the performance topic.