Order of execution for multiple triggers on same collection

We have two insert triggers for a collection; one which sets an auto incrementing field using a function and a second trigger which fires an EventBridge event for processing within AWS. Individually these work fine, but the order in which they are executed and logged is not consistent. Ideally, the function trigger fires first and the eventbridge second (in our case the auto incremented field is useful on the AWS processing side). We can work around this with GraphQL, but seems like it could be a common use case. Event Ordering is enabled, but I dont think is relevant here. Is there some way to guarantee the order that the triggers are fired?

Hi @James_Kucharski welcome to the community!

This is an interesting question. I have a couple of questions though:

  1. Is there a strict need for one trigger to be executed after the other? If yes, then I think the second trigger should be triggered by the first trigger and not the same insert event, don’t you think? Otherwise you’ll end up with a race condition.
  2. If strict ordering is not necessary, that implies that the two triggers can fire in any order and it won’t change the final outcome. If this is the case, is there a specific need in your use case to have one trigger fire before the other?

One idea that comes to mind is how about combining the two triggers into one when you need strict ordering of events?

If you need further help on this, perhaps you could post the requirements and the current scenario, along with some examples so we can understand the use case better?

Best regards

1 Like

Yes, in our case the order is strictly important. The modifications to the document in the first trigger are essentially relied upon by the event bus integration.

Because there is a setting to guarantee sequential execution of triggers on multiple documents, it seemed reasonable to be able to configure the order that multiple triggers are fired on a single document.

Certainly there are work-arounds, like firing the event bus trigger on an update made by the first trigger, but this seems less elegant for a number of reasons.