while developing custom actions I’m currently facing the following issue:
It seems for me that there is no way when my application receives the event to distinguish whether:
The event is a retry by monday servers because the first try took too long or had an invalid status code as response.
From the docs:
“If your server responds with any other status, or doesn’t respond within a minute, the monday platform will retry calling your endpoint every minute for 30 minutes .”
The user triggered another event without changing any data (e.g. by pressing a button twice)
Why is that important?
Lets say i have a custom action that increments a product quantity in a foreign system but takes 2 minutes to complete. Each press of a button should increment the quantity by one.
Now its impossible for me, to distinguish: Did the user click the button again or was it just a retry by monday? Yes, I could prevent retries by just sending a status 200 on the first received request. But then I would sacrifice all error handling capabilities monday offers.
It seems like there is already such an identifier for that, but its not included in the event payload.
The Run ID seems to be just the thing I need:
@gregra including you on this thread since it aligns with the conversations you and I have had - same issue.
@anton1 for your issue, what I’ve proposed to Greg previously is monday should implement proper 202 response handing.
A response of 202 would include an ID and URL to poll after a time specified (ideally developer controlled). This would let developers queue long running tasks as you described, return a 202 and instructions to query a URL with an ID to get the final results. In the meantime retries stop. Final results would include any success messages, or failure messages, etc. in line with the existing error handling capabilities.
It would also include the run ID in the original request in some fashion - which could be used as the ID for the callback for results.
This lets us queue long running jobs, not have needless retries consuming capacity in our systems (both app developer and monday), and still proved a user experience where end users are informed of failures in their workflows
Another use case is when there is a large number of events for an account, which exhausts API complexity. Today we have to pause execution and wait (if it doesn’t exceed the 60 second timeout), queue (with the same results as you describe, losing the error handling abilities), or reject and allow a retry. All of which have downsides today.
Being able to queue these events allows us to process them as complexity becomes available - including with queue shaping to optimize apparent application performance. Not all app events need immediate UI results, some can process as able, while others should happen ASAP.
