Run ID in the trigger body

Hey,
Today if there is an integration action that takes more than a minute monday will send another request and will ignore the running one (Also will not act on the respond of the previous one)
That means, if there is an action that takes more than 1 minute to run, we will handle the request more than once. Or acknoledge the request immideatly and handle a queue on our side.
The big disadvantage of the second option is that the users won’t be able to see that real status of their request in the integration activity log but will have to enter our activity log.
We find this very problematic, since users are used to the monday activity log and changing this behaviour for them may be a deal breaker.
I thought on a nice solution, instead of handling a queue on our side and then lose the ability to “update” the status of the activity log, I can handle the status of the integration on my side and respond to the client when I am ready. For that I need something to indentify the request, I think the Run ID can be a great thing like this.
If I will explain the flow
I get a request with Run ID “xyz”, I start to handle this request and keep a state of it and return a 429 status code (ideally 202 but I think it will mark as success).
Then every minute, I will get another request. If I don’t see this run id in my state I will handle it as above. If I do see, I will check the status of this request and return 200 if I finished or 429/202 again.
I know I can use the item ID as the id but then I limit the user to have only one action running for each item id in the period of running.
Thanks!

1 Like

I also think that a “Run ID” would be very useful. Stumbled across the same problem in the past.

– Simon

I’ve been asking for this for about two years… but now can’t find my feature request here in the community anymore.

@gregra this is the same concept you and I initially discussed about the 202 process for integrations, I can’t find any record of that request in the community now but I know you had gotten it.

3 Likes

We support this now!

Action payloads will now come with two pieces of metadata – a UUID for that particular action, and a UUID for the trigger execution.

Learn more in our changelog here.

@codyfrisch @xatxat @ram_perel - I’m going to tag this as released now :crystal_ball:

3 Likes

All I have to say is covered in this video:

3 Likes

Followup question, and I think the answer is yes…

The change log examples show a triggerUuid that is less than 32 characters and uses a z within it. Can we assume that this is just a bad example in the documentation and that both Uuids do in fact conform to /^[0-9a-fA-F]{32}$/ ?

@codyfrisch correct - it is updated!