Обмеження activity

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

Це передбачена поведінка. Якщо activity створює платіж, надсилає електронного листа, записує до іншої системи або змінює зовнішній ресурс, операція має допускати безпечне повторення.

Що це означає на практиці

• Типова ідентичність для ідемпотентності одного логічного виконання activity — activity_execution_id.
• Кожна повторна спроба також отримує власний activity_attempt_id.
• Worker може завершити зовнішню роботу, втратити оренду й повідомити результат із запізненням. Рушій може відхилити таке повідомлення, бо інший worker уже виграв стійку гонку, але віддалений побічний ефект уже міг відбутися.
• Код activity може використовувати введення-виведення, реальний час та змінний стан процесу. Код workflow не може. Зберігайте цю межу чіткою.

Рекомендовані шаблони ідемпотентності

Багато зовнішніх API підтримують передавання Idempotency-Key. Використовуйте логічну ідентичність activity із середовища виконання workflow, якщо віддалений сервіс це підтримує.

• Віддавайте перевагу activity_execution_id, якщо віддалена система має трактувати повторні спроби як той самий логічний запит.
• Використовуйте activity_attempt_id лише тоді, коли віддаленій системі потрібно розрізняти окремі спроби тієї самої логічної роботи.

Інші корисні шаблони:

• Записуйте за детермінованою назвою зовнішнього ресурсу чи природним ключем.
• Використовуйте upsert або таблиці усунення дублікатів зі стійким ідентифікатором як ключем.
• Робіть операцію природно ідемпотентною, щоб другий виклик нічого не змінював.

Багато операцій природно ідемпотентні. Якщо закодувати відео двічі, результатом усе одно буде те саме відео. Якщо двічі видалити той самий файл, друге видалення нічого не зробить.

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

Чого не слід припускати

• Не припускайте, що одна спроба activity завжди виконується лише на одному worker.
• Не припускайте, що повторна спроба означає невдачу попереднього зовнішнього побічного ефекту.
• Не припускайте, що запізніле завершення означає, що activity не виконувалася.
• Не переносіть побічні ефекти до коду workflow, щоб уникнути повторних спроб. Це лише перетворить проблему ідемпотентності на помилку детермінованості.

Повний контракт наведено в гарантіях виконання та ідемпотентності, а операторську модель відновлення — у збоях та відновленні.