durable-workflow/workflow 2.20.0

on GitHub

• Rollback, embedded Workflow package:
  • The 2.19.0 floor still applies. Releases before 2.19.0 ignore
    reused_recorded_at on reused signal, memo and search-attribute events,
    so a redrive successor with those events can replay with a different
    workflow time and deadlines there. Keep 2.19.0 or later workers, or
    confirm no such history can replay, before rolling back below 2.19.0.
  • From 2.20.0 to 2.19.0: 2.20.0 changes no replay code. 2.19.0 replays,
    imports and resumes a 2.20.0 successor that reused an applied update or a
    chained signal wait with the same workflow state, output and next
    command.
  • 2.19.0 refuses to redrive a failed run that 2.20.0 redrove with a reused
    update (unsupported_history) or a reused signal wait
    (mismatched_signal_receipt) before any write. A request for a run that
    already has its successor returns that successor.
  • On 2.19.0, run detail shows redrive links as diagnostic fallbacks.
  • Service-mode SDK workers stay behind the
    service_redrive_history_not_qualified fence.
• Redrive a failed run whose workflow applied an update before the failure.
  The successor records the update's acceptance, application and completion
  with reused_from_run_id and reused_recorded_at, ahead of the step it
  ran before, and replay runs the update handler again from its recorded
  arguments so the workflow state matches. The update is not delivered again.
  A rejected update, and one the failure closed before it ran, are not reused.
  Only three update shapes are accepted, in history order: a rejection, an
  acceptance closed by the failure, or an acceptance, application and
  successful completion with identical arguments. Every event in each shape
  must name the same update, command and handler and belong to the source run.
  An acceptance closed by the failure must record a terminal reason and a
  failure, with no result and no step. An update the source
  accepted but never resolved is refused with unsupported_pending_update,
  any other shape or binding with mismatched_update_history or
  incomplete_update_step, an externally stored update payload with
  external_update_payload_not_supported, and an inline payload that can't be
  decoded with unavailable_update_payload. A run a service worker started
  that applied an update is refused with service_redrive_history_not_qualified
  (#864).
• Redrive a successor that itself reused signal waits or updates. A reused
  payload keeps the run that first recorded it, and reused_from_run_id names
  the immediate source, so a chain of redrives reuses each step once.
  reused_from_run_id and reused_recorded_at come as a pair on every reused
  update and signal event. A reused event keeps its original time, and a
  history where one key is missing, blank or names another source is refused.
  Any external_storage key on a signal payload counts as external, even a
  null one. Before,
  redriving such a successor was refused with mismatched_signal_receipt
  (#864).
• Run detail and describe report a redrive link as typed lineage. The
  successor's parents and the failed run's continuedWorkflows show
  link_type: redrive with history_authority: typed_history and
  diagnostic_only: false, because the successor's WorkflowStarted records
  recovery_kind: redrive, continued_from_run_id and workflow_link_id.
  Both sides take the step (resume_step_sequence) and time from that event,
  not from the link row. The start must name the successor's own run and
  instance, an earlier run of the same instance as the source, a nonblank link
  id and a positive resume step, and exactly one redrive link row must join
  that source to the successor under that link id. Before, both sides showed
  a diagnostic-only fallback. A link the successor's history does not confirm stays a single
  diagnostic fallback (#864).

Full changes: 2.19.0...2.20.0