website logo
⌘K
Explore our documentation
Contact APIANT support
What is APIANT?
Automation Editor
Key Concepts
Account Management
Managing Automations
App Connections
Building Automations
Alert Mappings
Troubleshooting
CRMConnect: Mindbody → HubSpot
CRMConnect: DonorPerfect → HubSpot
CRMConnect: DonorPerfect → ActiveCampaign
MailConnect: DonorPerfect → Mailchimp
ShopConnect
ShopConnect Settings
Sync Products
Manually sync Mindbody services/pricing options to Shopify
How to tag products in Shopify to prevent sync during sales sent to Mindbody
Retrying orders from Shopify → Mindbody
Manually pushing Mindbody orders to Shopify
Mindbody Pricing Discontinuation: Integration with Shopify
Guide to manually syncing Mindbody Packages with Shopify Products
Features that are not supported in ShopConnect
Automation Alert Reports
Linked Accounts
ZoomConnect
New features in version 4
Settings
General
Email & SMS
BOTs
MINDBODY
Zoom
ZoomConnect Mindbody Appointments - Setup and requirements
Troubleshooting
Assembly Editor
Key Concepts
Account Management
API Key Management
Managing Content
Building Assemblies
API Integrations
Other Assembly Types
Keyvalue Storage
Assembly development cycle
APIANT for Integrators
Help Forum
Automation Templates
Development Server
Module IDE
Shared App Connections
Tenants and Linked Accounts
APIANT Inline
Supported functionality
Embed Inline
Sandbox
Docs powered by
Archbee
Assembly Editor
API Integrations

Automatic Error Retries

5min

The system has a config setting for defining errors that are to be automatically retried by the system:

Document image


For defined retryable errors, the system will automatically retry the failed trigger data row up to 8 times according to this schedule:

  • 1 minute
  • 2 minutes
  • 5 minutes
  • 10 minutes
  • 30 minutes
  • 1 hour
  • 2 hours
  • 4 hours

By default, the system's retryable errors include:

  • When an HTTP Transaction module or OAuth Transaction module, or any of their variants, returns an HTTP status code >= 500 and the module is configured to halt the assembly upon errors
  • When an HTTP Transaction module or OAuth Transaction module, or any of their variants, encounters a communication-level error occurs before the API can send a response and the module is configured to halt the assembly upon errors

The "halt assembly if error" setting is found here:

Document image


The automation's action must also be configured to "halt on any error" in order for the system to auto-retry any retryable errors:

Document image


Generally, only transient errors are configured to be retryable, where it makes sense that the failed transaction might succeed after waiting for some time.

The system retries failed transactions at the point of failure in the automation’s logic.

Retryable errors within subroutines

If an automation uses a subroutine and that subroutine encounters a retryable error, the system is able to retry the error from that point and continue processing if the failed action no longer encounters an error.

Retryable errors within executed child automations

If an automation executes a child automation via the System app's "execute automation" action and that child automation encounters a retryable error, the retry occurs from the parent automation, not the child.

This means that the retry processing does not pick up where it left off. The parent automation will re-run the child automation from its beginning.

Updated 07 Mar 2023
Did this page help you?
PREVIOUS
Two-Way Sync
NEXT
Integration Decision Trees
Docs powered by
Archbee
TABLE OF CONTENTS
Retryable errors within subroutines
Retryable errors within executed child automations
Docs powered by
Archbee