I’ve written my code using the @mondaycom/apps-sdk Queue. In the development environment, there is no queue implementation; it directly makes an HTTP call to the job endpoint.
I’ve made some assumptions about retry and back-off behaviour while developing the code. However, I couldn’t find detailed information about the Queue in the documentation. Could you please help clarify the standard behaviour of the queue, especially regarding the number of retries in case of failure?
Additionally, is there an endpoint to query the number of failed jobs or status of a message enqueued? What is the back-off policy, and can we set it based on the type of error? Currently, I’m assuming it’s not customisable, so for permanent failures, I return a 200 status and send a notification to the user.
Are there any other important details I should consider?
I’m feeling a bit edgy to go with this implementation as I’m approaching app submission to the marketplace soon. Your guidance would be greatly appreciated.
@gregra can you please confirm this? Also, what backoff policy is applied with the retries? My code depends on a third-party API, and there might be times when the upstream service is unresponsive, so an incremental backoff delay strategy would be ideal.
Additionally, what are the recommended best practices for handling permanent failures of a background job? Currently, I send a notification to the user.
@Matias.Monday Would it be possible to add the queue incremental backoff delay strategy as a feature request? I think it’s very common to use queues for interfacing with APIs, so this type of backoff policy would be very helpful for many integrations.
Without this feature, it really limits the usefulness of queues in monday code.