I’m encountering the following issue, I have a “Notification” base, which is essentially an “extended” base, which has 3 tables that are synced tables from another base.
The goal of the setup is to run asynchronous automations into a different base, due to the 25 automations limit of Airtable. This way, I can have 25 asynchronous automations in this secondary base.
It’s mostly about sending notifications, emails, slack, etc. Stuff that doesn’t need to happen immediately.
That being said, we noticed the sync doesn’t always work, when changes are made in the main base, they are not synched into the secondary “Notifications” base at a 5mn interval rate.
I believe it’s due to “Automatic syncs will eventually stop on bases that don’t have any recent activity. To keep automatic syncs active make sure that some kind of action is being performed in the base on a regular basis.” - Source
So, my question is, what is an activity? Because we do perform API reads regularly on the secondary base. But, those automations seem to be triggered as soon as one of us opens the base.
Is there additional documentation about how this “freeze” behavior works? Aren’t API reads considered as an action towards a base?
We’re also affected by the exact same issue. One of the synced tables stops after no “recent activity” but resumes after viewing the synced base via web UI. We also do regular API reads to the synced base, too.
This might be okay for UI based workflows but creates a lot of issues for API consumers. I can totally imagine daisy-chained tables breaking or falling out of sync or worse yet, a small subset of chained tables stops syncing and you’ll have inconsistent data all over the place.
So, repeating the same question, what’s an activity? Any way to stop sync freezes?
You can probably lower that to consume less automations. I guess even 2h would work fine.
You might need to configure this on all destination tables, but I’m not sure.
I kind of feel like I ran into issues when not all the tables where read recently, but maybe “writes” behave differently and keep the whole base in-sync. :person_shrugging: