I am trying to create a flow in which users of type B can Accept or Reject certain orders. Either by accepting or rejecting they should get rewarded and their balance get updated.
The problem is that when Accept/Reject decisions are made fast, the balance does not update accordingly. It seems to me that is related to the way I update the balance which is not very straightforward.
Right now, as the only way to access the user balance I found is through a query, I run 3 success event handlers after the ClickActionHandler(Accept or Reject). These are:
getUserInfo query (gets the user balance)
updateBalance query (updates the balance using getUserInfo balance + the order reward)
updatePending query (to update order table and remove this order from pendings)
In my opinion and from what I tested out, the problem is that when decisions are made fast enough. The second one's getUserInfo query runs before the first decision's updateBalance so the balance is updated just by the second one's reward.
I was hoping to find a way in which balance updates do not need to query again the database but just increment the actual value by "order reward". Or at least to somehow order these queries or limit them.
Let me know if any more information is needed to understand the problem or help me figure this out!
Thank you very much for any kind of guidance on the matter
Indeed, if you have 3 success event handlers in the same query, they may run into competition and not trigger in the order you want.
You could actually change the event handler in the button that's triggering ClickActionHandler and replace it with a Run Script that could look like this:
By doing this you save yourself the time of setting event handlers in each query and conditioning them to whatever condition it should be checked before running. You can also pass additional scope adding data from the queries if needed.
Your proposal works for maintaining order within the click event. And for that I appreciate your help. But I am still getting issues while updating the balance since different events (decisions) running almost at the same time get old balance data so just one event is updating the balance really (the last one).