Час очікування запиту минув. Чи надсилати його знову?

Підтвердження може загубитися після виконання роботи. Концептуальну ілюстрацію створено за допомогою AI; реального запиту чи мережевого тесту не зображено.

Запит на створення завдання виходить із застосунку, індикатор очікування зникає, а підтвердження не надходить. Виникає спокуса надіслати запит знову. Але яку проблему це розв’яже: завдання, що не було створене, втрачене підтвердження чи результат, який відправник іще не знайшов? Ці ситуації потребують різних рішень.

Відсутність відповіді залишає результат невідомим

Уявімо вигаданий редакційний процес. Інструмент підготовки чернеток просить трекер створити одне завдання перевірки для одного брифу. Трекер може зберегти завдання, перш ніж підтвердження загубиться. Або запит може взагалі не дійти. Це вигадані можливості, а не звіт про реальну інтеграцію чи виконаний мережевий тест.

Amazon Builders’ Library пояснює цю невизначеність на прикладі створення ресурсу: відсутність відповіді не встановлює, чи відбулося створення. Повтор неідемпотентної операції може породити небажаний дублікат. Звіряння результату шукає докази наслідків початкового запиту, перш ніж робити нову спробу створення.

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

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

Визначте, чи дозволяє помилка повторну спробу

Рекомендації AWS щодо retry with backoff стосуються тимчасових збоїв, зокрема короткочасної недоступності. Вони застерігають, що часті повтори можуть посилити конкуренцію за ресурси й погіршити роботу сервісу. Backoff розділяє спроби паузами; exponential backoff збільшує інтервал очікування. Очікування змінює час повтору, а не його безпечність.

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

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

Обмежена політика повторів також задає максимальну кількість спроб і загальний часовий бюджет. Backoff подовжує очікування відправника, а схема AWS передбачає зупинку після невдалих спроб. Обирайте межі за реальним контрактом сервісу й кінцевим строком процесу; ілюстративні налаштування не є універсальними значеннями.

Для вигаданого запиту на перевірку ще не конкретизована вимога звучить так: «перевіряльник іще має час опрацювати бриф». До впровадження її потрібно перетворити на конкретний бюджет. Цей розділ не задає кількості повторів чи графіка затримок. Після вичерпання бюджету запропонована гілка завершується нерозв’язаним випадком і визначеною відповідальною роллю, а не твердженням, що завдання не існує.

Idempotency належить до контракту операції

Idempotency означає, що повтор того самого логічного запиту після успішного застосування не спричиняє додаткових передбачених побічних ефектів. Builders’ Library описує ідентифікатори запиту, які задає відправник, щоб виразити цей намір. Самих однакових payload недостатньо: відправник може цілком правомірно хотіти два схожі ресурси.

Сервіс має визначати область дії ідентифікатора, допустимі параметри та строк збереження. У матеріалі AWS про ідемпотентні API пояснено, що вимоги до збереження відрізняються. Повторне використання ідентифікатора зі зміненими параметрами може бути відхилене за контрактом сервісу. Idempotency не вимагає побайтово однакових відповідей і не обіцяє універсальної доставки exactly-once.

У нашому прикладі логічний намір — «створити перевірку для цієї версії брифу». Повторення того самого наміру зберігало б його ідентичність лише за явної підтримки такої поведінки трекером. Запит на окрему перевірку — новий намір. Зміна версії брифу зі старим ідентифікатором змішала б два запити й зробила очікуваний результат неоднозначним.

Перш ніж покладатися на запропонований трекер, його розробники мають з’ясувати: де розпізнається ідентифікатор, як довго він зберігається та як знайти завдання? Після закінчення строку збереження не можна припускати, що старий ідентифікатор досі запобігає дублікатам. Посилання, збережене лише у відправника, не замінює відсутнього контракту отримувача.

Усуньте невизначеність, перш ніж закривати випадок

Припустімо, вигадана перевірка підтвердила початкове завдання. Процес може продовжити роботу з його ідентифікатором, навіть якщо початкове підтвердження так і не надійшло. Якщо перевірка неостаточна й немає підтверджено безпечного дозволеного повтору, запропонований результат — передавання випадку: ідентифікатор запиту, версія брифу, спостережені докази та нерозв’язане питання. Жодна гілка не створює непомітно ще одну перевірку.

Матеріал «API, JSON і webhooks: простежмо одну подію між двома застосунками» пояснює попередні межі між читабельним повідомленням, підтвердженням отримання та завершеною роботою. Цей розділ додає наступне рішення: встановити відоме, перевірити допустимість і безпечність повтору та залишити невизначеність видимою, коли доказів недостатньо.