Allow to set the maximum number of integration requests an app can handle

[anon29275264]

I have a couple more specific technical requests open that are in support of this concept.

Integration action - 429 should pause queue for board integration

Currently when we return a 429 to an integration action, the action will retry (or at least is supposed to @basdebruin) at 60 seconds from when it last tried. I have a separate request open for honoring retry-after headers. Scenario: User has changed status on 500 items, triggering an integration. Monday queues these 500 operations and begins processing (I think its about 20 initially). If we return a 429 with a retry-after then the entire queue should pause. Any actions with a 429 should be co…

Support retry-after on 429 for integration actions

Support the retry-after header for integration actions on 429. If we need the action to retry in 35 seconds (for example third party API is rate limited) then we should be able to pass that to monday to retry in 35 seconds. This will reduce needless retry waiting for the user - their actions will be completed sooner. I still believe the best queue for rate limited actions is monday’s queue, since that will show in-progress rather than succeeded/failed to the user in the activity log.

Long-lived actions

Implement a 202 based method for long-lived actions. Either of these methods will work: 202 response. We return an in progress message, the URL monday should check for updates, and how long to wait for the update. Polling would permit us to update in progress with an estimated time remaining, percent complete, etc.) 202 response. We return an in progress message. We then use an API method to post a call back with the status when completed. We could also post back progress statuses for complet…

Enhance integration activity to support success and in progress messaging

Today it is possible to provide failure messaging - and disable an automation if there is a failure (such as the stored token for an external service belongs to a user who doesn’t have access to the system any longer). enhance this capability to include the ability to return messaging on success (changed project state to xyz), and for in progress allow us to return the 2000 severity (which exists) and display that message for “in progress” states. For the in progress it would be something like…

Include remaining query and mutation complexities in action payloads

It would be really useful if the current “after” query and mutation complexity values, along with the reset in x seconds, were sent in action payloads. We know what our integration recipes will use minimally, to be able to get this information at our router (or before) means we can respond with an error to the event, causing monday to retry in 30 seconds with a new token (or better if we can specify a retry-after value). While we can query for the complexity of the query pool, there is no way …