I’ve been troubleshooting something for a while. Root problem is that database triggers not consistently firing.
If I bulk run a b/e workflow over a list of 10 records, and each b/e fires a database trigger, I get different results each loop. As in, different records are firing the database trigger. It appears random.
The database trigger is is a basic “when record created” logic.
Waiting does nothing. They don’t appear to be queued.
As in your backend workflow is creating a new record over a list of 10 existing records?
Have you checked the docs to see if you have hit any of DB trigger limitations?
As in I run a bulk action that makes changes to 10 database records.
Each change should fire a database trigger.
However, each time I run this, only a random number of records trigger the database trigger.
You’ll need to add a slight delay to the “api on list” action
Even though bubble say they can process the list without a delay in my experience it causes issues like you’ve described above - skipped data triggers etc.
Try adding a 0.1 or 1 second delay to the api on list step.
Also keep in mind that data triggers are only triggered by external actions and not internal backend actions.
frontend change = external
backend api workflow = external
backend custom event = internal
backend data trigger = internal
And although the origin of the trigger should be respected it drops at some point in the nesting chain - so if you use deeply nested custom events then you’ll likely need to add some api workflows to force the data triggers to actually trigger.
Data triggers are quite difficult to get consistently right.
I notice this doing bulk actions, which would be maximizing throughput (I assume). If some are getting lost, then I wonder if indeed the problem is too much happening at once.
If that’s the case, however, then they can’t be trusted at all. What happens when throughput is high with normal app usage? If triggers are getting dropped then I wouldn’t notice unless someone complained.
It’s so annoying that this can’t be relied on. It’s such a great tool in principle.
@fede.bubble is this a known issue? I’m not the only one experiencing this problem. Can you provide some insight why database triggers aren’t running consistently?
You’re experiencing race conditions if you are modifying a list field on a data type in your database trigger.
Triggers are pretty reliable in my experience and we can trust them.
In addition, remember that database triggers cannot trigger other database triggers.
Hm, maybe a race condition.
DB trigger detects when something is created (Cat) and adds that thing to different record type’s (Family) list of Cats field. The Family record already exists before trigger for Cat runs.
The success rate appears random. In a set of 10 records, it’s anywhere from 30% to 80% successful, with no consistency on which records work.
When I’m testing this, I’m using the same Family record for all ten different Cat records.
Do you think there’s a race condition when the list of Cats on the Family (the field that stores the list) is being set? As in the data in the Family record changes between read and write when a bunch of DB triggers for Cats referencing the same Family record makes changes to the Family record?
That would certainly explain the randomness and why it works if you loop the records with a delay.
Yes
Do I get points if I guess correctly that things are created in a backend workflow that you’ve scheduled using schedule API workflow on a list?
Partial points! I’m using the bulk update on a database view. So, sort of. It’s for a data migration step.
This topic was automatically closed after 70 days. New replies are no longer allowed.
