durable-workflow/workflow 2.20.1

on GitHub

• Rollback, embedded Workflow package: 2.20.1 changes no schema, history
  event or API. Rolling back to 2.20.0 or earlier brings back the duplicate
  sends and replay receives that #1010 describes. Rows written while 2.20.1
  ran stay correct, and a run that 2.20.0 later replays can add duplicates
  again. Service-mode SDK workers don't use MessageStream.
• Message stream calls in workflow code act once instead of on every replay
  (#1010). Workflow code runs again on each later workflow task, on every
  query and in a redrive successor's reused prefix.
  • outbox()->sendReference() used to write a new outbound and inbound
    message each time. A replay now returns the row the original send wrote,
    including a row written by the run a successor was redriven from.
  • inbox()->receive() and receiveOne() now return the messages that call
    consumed at that step, by this run or by the run it was redriven from.
    Before, a replay could return different messages or none, and could
    consume a newer message under the earlier step.
  • A query, a replay check or a redrive definition check never writes or
    consumes a message. A stream kept across a replayed update handler checks
    this on every call, so later sends still write.
  • Rows that earlier releases duplicated are not removed. Reads don't
    deduplicate them, and no migration can tell a replay duplicate from an
    intended identical send. A consumer that read the stream on an affected
    release should deduplicate by idempotency_key. A run with such rows
    matches its sends to the earliest rows and writes only new sends.
  • Messages that a replay or query on an affected release (2.20.0 and
    earlier) consumed under the wrong step stay consumed, and workflow code
    won't receive them again. Check streams that workflow code receives from
    for consumed messages the workflow never handled.
  • A replayed receive whose original call found no message still reads the
    stream again, because nothing records an empty receive. It can return a
    newer message, or a message that a later call consumed at the same step,
    for example through a stream kept in a property, which keeps the step it
    was opened at. Receive only after a signal or condition says a message is
    there, and send that signal before the message: a signal moves the run's
    shared message cursor past older pending messages (#1011).
  • A send is matched by its exact content (channel, stream, target,
    reference, correlation id and idempotency key), whatever the column
    collation. An identical row that code outside
    the workflow wrote for the same run can satisfy it, so give workflow sends
    their own idempotency key.

Full changes: 2.20.0...2.20.1