Огляд

Workflow й activity перебувають по різні боки стійкої межі та мають різні обмеження. Код workflow відтворюється, а код activity виконується повторно. Це різні операції, і правила випливають із цієї відмінності.

Почніть із ідемпотентності та детермінованості workflow, щоб побачити пряме порівняння й конкретні приклади того, чому жодна з цих властивостей не передбачає іншу.

• Код workflow має бути детермінованим. Рушій відтворює історію, щоб відновити стан workflow щоразу, коли він продовжується: на іншому worker, після перезапуску, розгортання або під час тривалого виконання. Відтворення повторно викликає тіло workflow, а не activity, тож workflow має ухвалювати ті самі рішення в тому самому порядку, коли бачить ту саму історію. Читання реального часу, поточного кешу, випадкові числа, мережеві виклики та інші джерела змін заборонені в тілі workflow. Використовуйте Workflow::now(), sideEffect(...), activity та подібні засоби для переходу через стійку межу.

• Код activity має бути ідемпотентним. Спроби activity виконуються щонайменше один раз. Повторні спроби, завершення оренди й повторна доставка можуть спричинити повторне спостереження тієї самої логічної роботи. Це передбачена поведінка, а не умова помилки. Фреймворк записує щонайбільше один кінцевий результат спроби на рівні стійкого стану, але тіло activity може почати виконуватися кілька разів, перш ніж рушій побачить повідомлення переможця. Вважайте повторне спостереження нормальним і використовуйте ключ ідемпотентності, детермінований цільовий ресурс або природно ідемпотентну операцію, якщо зовнішній побічний ефект не має дублюватися.

• Event sourcing зберігає історію й не повторює побічні ефекти. Рушій записує кожен стійкий крок як типізовану подію історії: завершення activity, спрацювання timer, отримання signal чи запис побічного ефекту. Відтворення читає цю історію та повертає збережені результати тілу workflow. Воно не надсилає activity, timer чи signal повторно. Події стійкого стану для заданого ідентифікатора записуються рівно один раз на рівні історії, навіть якщо транспорт доставив роботу кілька разів.

Разом детермінованість та ідемпотентність дозволяють рушію продовжувати workflow через розгортання, перезапуски worker та розподілені повторні спроби без втрати позиції та без дублювання зовнішніх побічних ефектів, які застосунок уже зробив безпечними для повторення.

Дивіться гарантії виконання та ідемпотентність, щоб зрозуміти публічний контракт v2 щодо відтворення, повторної доставки, завершення оренди та стійкої історії з записом рівно один раз. Потім використовуйте обмеження workflow для конкретних правил написання, які зберігають детермінованість відтворення, та обмеження activity для рекомендацій щодо ідемпотентності, які роблять виконання щонайменше один раз безпечним.