Actually not sure if it’s a race condition or just me not organising my workflow accordingly.
I have a web book / API endpoint which accepts events (I will call these event things) passed from an API. Each event as 6 key pieces of data one of which corresponds to a thing (I will call this my events group thing ) in my database. 1st I do a search for the event group thing based upon one of the pieces of data in the event thing and add it to the new event thing… So far so good… Now when I try and update the event group thing with an ADD to the event group things list of event things… I get intermittent results… On average only about half of the event things were added but strangely enough every event thing has the event group thing. The event things occur in a high repetition on average about a 1 second between each event thing hitting my endpoint.
The only way I found to get around the issue is to schedule a workflow after about 15 minutes which does a search through all my event things for the event group thing which is always funny enough added and then add these as an ADD LIST. I know and I’m very well aware a race condition is not restricted to bubble but if anybody has guidance on a workflow for I volume of events being written in workflows it would be much appreciated
oooh…thanks for the quick reply Nigel. I done the search of the forum and noticed a few posts but I thought I’d re-ask… Can I inquire when you mention ‘space out the workflows’ how you actually going about this?.. I’d actually tried to run a scheduled workflow on each event but I cannot get minute around how you space these out… Funnily enough if the events on their own accord are spaced out due to the speed at which their firing and these occur above for 5 seconds in between each then there is no problem.
Your experience Nigel what is the optimal workaround… Spacing the workflows out or just scheduling a ‘search’ add list update list
In similar situations I’ve had success with scheduling the processing to be done in the future, and randomizing the time by adding a random number of seconds to the current date/time. I record the webhook in the db and then schedule an api to run, passing it the thing I just created in the db. The random number spaces them out enough to prevent most issues. Maybe that would work for you here?
@NigelG@mebeingken@reger-alexander thanks all the valuable input coaching… I will put each of the suggestions through the works and report back on the optimal and post an update here for anyone else who finds the thread.
The issue seems to be one of updating the same thing’s list multiple times.
Creating multiple things doesn’t seem to be the issue, it is the “create thing then add that thing to a list” that fails on the last step.
As above, if you can delay or separate that last part it may help. Ultimately, it is for Bubble to fix this known issue with consistency with workflows.
I think the idea of single-threading webhooks by storing on the Bubble Database as simply as possible is not a bad idea.
In the past I have had similar issues with Mongodb locking - we ended up single threading by storing the requests on a Redis queue, but not sure how practical that it.
@reger-alexander the :plus item produced far better results than my initial add item, thanks but i’m my case its still not yielding a 100% attach rate…still vary s depending on load. @mebeingken spacing the scheduled wf works thanks in my case.
Thanks @NigelG…for all the benefits with Bubble there are some areas where things might not be optimal…i can live with challenges
I put a fake step to avoid the race conditions
I had an issue where I wanted to add a list of things to a thing I just created.
Eventually I done the following
created the thing parent,
run a list on the children i wanted to create,
which went like this
create child
initiate buffer workflow
buffer workflow runs actual workflow
actual workflow does a search for the thing and attaches it to list
