Understanding error handling


Introduction

Introduction

Cargo's modular structure provides a versatile and powerful platform for building workflows, similar to assembling LEGO pieces. This flexibility enables users to create a broad range of processes, but it also introduces the risk of bugs and errors.

This explanation seeks to impart some best practices that will assist the user in minimizing errors as well as reacting to them where they may occur.

Effective Cargo users are adept at both process design and issue identification. The best practices include:

  • Mocking the workflow logic: Beginning with a minimum version of the workflow. This approach allows for early identification of core business logic flaws.

  • Adding complexity in layers: Gradually add nodes to the workflow and test their execution individually, reviewing the logic or data mappings within for errors or inconsistencies.

Phases

Testing in phases

Cover image

Cargo's deployment process reflects common software development practices:

  1. Node testing: Create and test the workflow using a sample record from the start node. The start node is present in every workflow to encourage users to design processes in their simplest form, using a small set of test values.

  2. Workflow testing: Test the initial release by importing a batch of records from the data model. The Runs panel in the workflow editor includes an option to Import records meeting a filter condition to allow testing for edge cases across a smaller sample on the latest published version. This facilitates efficient testing at a small scale but is only available once a version is published.

  3. Trigger testing: Trigger-based enrolment stage, automatically enrol records from the segment whenever the trigger conditions are met. Once a workflow is published and enabled and linked to a segment, automatic enrolment will take place.

Error types

Error types

Cover image

Whenever a node encounters an error during execution, it will display an error message in the right-hand panel. Errors in Cargo workflows can arise from several sources:

  • Not connected: A node is not linked to a necessary preceding node in the execution flow.

    • Tip: Perform node testing to ensure all nodes run as expected.

  • Wrong mapping referenced: A problem originating from incorrect referencing of a node mapping within the correctly referenced node.

    Tip: Use the IN-OUT display after a run to spot reference errors.

  • Typo in reference: Typographical errors in a node or its expressions are common.

    Tip: Use autocomplete previews as much as possible when referencing precedent nodes in an execution flow.

  • Expression syntax: Violations of JavaScript syntax or Cargo's templating rules within expressions can cause errors. Common issues include:

    • Using methods not compliant with JavaScript.
    • Not fulfilling all syntax requirements of the JavaScript method used.
    • Attempting actions not allowed by Cargo's expression template.
    • Violating the templated rules for creating expressions in Cargo.

  • Data type issues: Expressions referencing incorrect data types can lead to errors. For instance, trying to use a string method on a non-string object.

  • Internal server errors: Often invoked by syntax errors in expressions. Refer to Cargo's team for clarification.

  • Network errors: Connectivity issues temporarily affecting the workflow, usually resolved by repeating the action.

  • Saving errors: Problems encountered while saving changes in the workflow draft.

    Re-running failures

    Re-running failed runs in workflow and trigger testing phases

    During workflow testing, trigger testing or production runs, you might encounter runs that fail to execute correctly and need to be re-run post-corrections to the execution logic.

    Cargo provides a feature to re-run these failing nodes directly from the left panel.

    This allows you to quickly address issues without having to restart the entire workflow. The concept works because re-runs will be triggered on the latest published version of the workflow, which means that if you correct the errors and publish, re-running from the left panel will execute the corrected logic.