Uploaded image for project: 'Serverless logic'
  1. Serverless logic
  2. SRVLOGIC-3

[core] Workflow state persistent storage

XMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Done
    • Icon: Blocker Blocker
    • 1.24.0
    • None
    • serverless-workflow
    • None
    • False
    • None
    • False
    • 2022 Week 32-34 (from Aug 8)

      Motivation

      Several use cases such as callbacks, async calls and the SAGA pattern require persistence of states for long-running workflows.

      Goal

      Enable PostgreSQL persistent storage for workflow states.

      Scenarios

      As a developer, I need to store the state of my long-running workflow so that it doesn’t consume CPU resources when waiting and can resume its execution upon an event/request arrival.

      Expected outcomes

      Workflow services can optionally connect to PostgreSQL persistent storage to store its state during a wait state.

      Persisted workflows resume their execution upon an event/request arrival.

      DB should be self-cleaning

      Events in combination with persistence is not 100% reliable solution - acceptable for DP1

      Auditing (i.e. storing historical data about past workflows) is out of scope

      Workflow versioning is out of scope - it's recommended to use version as part of workflow identifier
       - changing a workflow without updating workflow id can have unexpected behaviour with the already active workflows

            cnicolai@redhat.com Cristiano Nicolai
            ibek1@redhat.com Ivo Bek
            Marian Macik Marian Macik
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: