Fixing connection errors

app modules output the connectionerror when the app is unavailable for example, the app might be offline for maintenance {{product name}} uses the http 503 and 504 status codes to identify the connectionerror {{product name}} follows the standard error codes and their definitions note that it is possible that the third party may not fully comply with the standard when a module in your {{scenario singular lowercase}} outputs the connectionerror , you should check the status page of the module app chances are that the status page will have the url https //status domain , for example https //status make com when {{product name}} recognizes the module output as the types of errors docid\ n4w0yaeop7a a4vfw ebp and you don't use any error handling, {{product name}} acts depending on the following attributes {{scenario singular lowercase}} scheduling enabling of the incomplete executions incomplete executions disabled incomplete executions enabled scheduled {{scenario singular lowercase}} {{product name}} pauses the scheduling of the scenario for 20 minutes {{product name}} doesn't rerun the scenario {{product name}} pauses the scheduling of the scenario for 20 minutes {{product name}} retries the incomplete execution with the incomplete execution exponential backoff docid\ le2snkujgl9uzqfm 0v3i instant {{scenario singular lowercase}} {{product name}} reruns the incomplete execution with the {{scenario singular lowercase}} exponential backoff docid\ le2snkujgl9uzqfm 0v3i {{product name}} retries the incomplete execution with the incomplete execution exponential backoff docid\ le2snkujgl9uzqfm 0v3i how to handle the connectionerror to handle the connectionerror , you can use the fixing rate limit errors ratelimiterror docid\ oxgtalgvur0yzkn ux9wk the most efficient strategy is to use the error handler docid\ hxe6n1fool691glswodgy to rerun the {{scenario singular lowercase}} after a delay if your {{scenario singular lowercase}} triggers with an types of modules docid\ pdopibceckcbomppkplmy (for example, a custom webhook module), consider enabling sequential processing in scenario settings with sequential processing, the trigger module processes incoming data one by one in the order they arrive otherwise, skip this step if a {{scenario singular lowercase}} has incomplete executions and sequential processing enabled, {{product name}} pauses the {{scenario singular lowercase}} until the incomplete executions are processed to keep the order of incoming data add the break error handler to the module that is causing the errors consider setting the delay and the number of attempts according to the importance and the schedule of your {{scenario singular lowercase}} for example, if the app has occasional downtime for maintenance for a few hours with no availability, it might be best to set a lower number of attempts with longer time periods between them on the other hand, if the app is occasionally unavailable because it's overloaded, and the {{scenario singular lowercase}} is important for you, it might be best to use a short time period (a few minutes) with a higher number of attempts enable incomplete executions in the {{scenario singular lowercase}} settings {{product name}} will save bundles that caused the error for example, if you would use the webhook trigger to ask questions to chatgpt , but the chatgpt app is sometimes overloaded with requests and sending back errors, your make and make settings with error handling could look like this whenever the create a completion module outputs the connectionerror because the openai servers are overloaded or unavailable, {{product name}} creates an incomplete execution with the create a completion module after the delay set in the break error handler, {{product name}} reruns the create a completion module if the rerun succeeds, {{product name}} will continue scheduling new {{scenario singular lowercase}} runs if the rerun fails, {{product name}} reruns the module again after the delay, up to the number of attempts set in the break error handler settings