This is a request for an epic focused on a set of features. These are all related requests which follow a theme. I would say a vote for this request should be considered a vote for all of the included requests. I’m just rolling this up because the number of requests was growing.
The primary goal is to minimize retries globally - across mondays infrastructure, including monday-code, and developer infrastructure. At the same time, only delay processing in queues the minimal amount of time required for whatever condition to be resolved (external API, monday.com API etc. rate limits).
Additionally, provide accurate feedback to the users as to why the action is not yet complete (in progress status), and improve how they get help when there is a problem.
Here are links to all of the related individual requests:
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…
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…
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.
We have multiple apps using integrations. One of which is Location Importer . This app is used to convert Text columns to a Location column, a typical bulk action. monday limits users to bulk change 500 items at once but when you configure an automation to be triggered when “An item is created” you can literally trigger thousands of requests by importing an Excel or CSV.
For the app to work it has to perform some other API calls to the monday API such as retrieving the text value (query) and wri…
Enhance the newly released “runtimeMetadata” object sent with integration actions to include the number of retries remaining before monday considers it a failure.
This way we know when we should return a meaningful error message (if possible) rather than allowing another retry. (For example a third party system is having connectivity issues, we might allow monday to retry but eventually need to report back to the user “external system is unresponsive”).
We can count the times we’ve seen it, bu…
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 …
Add support for 429 responses to the monday-code queue that obey the retry-after header so that monday-code developers can control queue rate when the monday.com API hits its low complexity limits / rate limit.
Also do not treat 429 errors as a bad thing and punish the app by turning off retries or queueing. We don’t control monday’s unwillingness to support higher complexity limits for larger accounts - and developers shouldn’t be punished for that.
Right now when we return an error object with a severity code, we can return a message.
We need the ability to include the following additional items that will appear in the UI
Support email to send support requests to rather than support@monday.com when using the report issue button. This could be an app configuration setting or such.
Support link for issue/generic link for the recipe that can be displayed. This returned in the error response.
A “submit a ticket” link, which we can craft to …
If you have other associated requests to add let me know.