Yeah we run into this all the time. Huge race condition. This is because workflows do NOT execute sequentially across all actions as one would think. It actually executes them based on action type in three different sequential buckets, in parallel. The actions are split up as:
-API calls
-DB actions (make changes/create new thing/etc)
-Everything else / State changes / Visual actions (hiding/animating/display data/etc)
The engine appears to pre-scan your workflow, schedule API calls it can first, make DB changes second, and then call anything else last. We solve this via two primary methods:
calling an action with conditional “Result of stepX is not empty” on a DB action will ensure the DB is evaluated prior to the conditional action ensuing
SCHEDULING (not triggering) a custom event will ensure it happens apart from the race condition (hence place your latter conditional action in a custom workflow then schedule it with a 1 second delay) EDIT: also add a terminate workflow conditional on the start of your scheduled workflow to abort if your undesired fail-state occurs regarding your booking)