Delay between the data displayed in the UI and the data retrieved via the API

Your Setup:

  • SeaTable Self-hosted
  • SeaTable Version (only necessary for self-hosted): 5.2.7
  • Hardware or environment you use - Virtual Mashine with RH8
  • SeaTable Edition (Developer or Enterprise) - enterprise edition

Describe the Problem/Error/Question:

After some period of operation, a delay has appeared between the data displayed in the UI and the data retrieved via the API (whether SQL or HTTP GET).
That is, there are rows visible in the UI that are not present in the API response, and vice versa. However, after some time, the data eventually synchronizes on its own. Currently, this delay is approximately 10 minutes.

Restarting all containers is undesirable, as we want to preserve the full history of changes.
No suspicious or critical errors have been observed in the logs.

What could be the cause of this issue?

Error Messages:

no error messages.

Example of a code block for error messages

I cannot confirm this behavior. Data is visible immediately via API. Is your setup somehow special - besides that you use RH8 and that you use an outdated version?

Thank you for the response.
There are no special features.
After restarting the containers, the problem will most likely disappear again.
But it has already occurred several times - after some period of normal operation with ST (about a month or so), this effect appears.
The API requests are not complex (usually select * from tbl … or similar get queries).
It’s also not related to database sizes - it occurs on different databases. Now it’s even appearing on a newly created database.
The VM is not heavily loaded, swap is empty.

What kind of storage do you use? Local disk, network storage or object storage?
Do you use a local mariadb database?

Yes, installing everything on one host.
Local disk and local MariaDB database.

The data retrieved via API is return by dtable-db component. The data displayed in the UI is retrieved from dtable-server component.

dtable-db need to read MySQL database to fetch changes made to the base in dtable-server component and cache it in its memory.

For your issue, you should check if dtable-db can correctly read MySQL database. You can check dtable-db.log to see if there are any errors.

In summary, it is not a bug, but a deployment issue.

daniel.pan SeaTable Developer - Solution

It’s a pity the issue was closed this way.
I was hoping to help find a solution to a hard-to-reproduce issue. (This is my second message about the same issue, and a reload restores the system to a working state.)
I deliberately kept the system in the problematic state for diagnostics.
As mentioned above, ST is deployed strictly according to the instructions on a single host—so there cannot be any “deployment issue.”
But such dismissive replies dramatically undermine trust in the product.

We are confident that there is generally no such a bug in the code.

I have posted an explanation of how the system works to assist you in debugging the issue. If you could provide us with more information and logs related to the system’s operation, we would greatly appreciate it.