Якщо інтерфейс повідомляє про помилку, повторити спробу? Завдання документування повинні спочатку визначити, які збої можна відновити

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

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

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

Як повторити спробу після того, як завдання документа повідомить про помилку? Висновок одним реченням

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

Спочатку визначте, чи повторна спроба призведе до повторення завдань.

Тайм-аути POST особливо неприємні. Якщо клієнт не отримує відповіді, це не означає, що сервер не створив завдання. Якщо інтерфейс не має ідемпотентних ключів і не має механізму запиту завдань, сліпе повторне надсилання може створити кілька завдань перекладу.

Таким чином, стратегія повторної спроби повинна спочатку слідувати контракту інтерфейсу, а не просто переглядати код стану HTTP.

Запишіть кількість разів і бюджет очікування як чисті функції

from enum import Enum

class Failure(Enum):
    TRANSIENT = "transient"
    AUTH = "auth"
    BILLING = "billing"
    INVALID_INPUT = "invalid_input"

def delay_for(kind, attempt, replay_safe):
    if type(attempt) is not int or attempt < 0:
        raise ValueError("invalid attempt")
    if not replay_safe or kind is not Failure.TRANSIENT:
        return None
    schedule = (1, 2, 4)
    return schedule[attempt] if attempt < len(schedule) else None

assert delay_for(Failure.TRANSIENT, 0, True) == 1
assert delay_for(Failure.TRANSIENT, 2, True) == 4
assert delay_for(Failure.TRANSIENT, 3, True) is None
assert delay_for(Failure.TRANSIENT, 0, False) is None
assert delay_for(Failure.BILLING, 0, True) is None
assert delay_for(Failure.INVALID_INPUT, 0, True) is None

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

Виробниче середовище також має враховувати такі моменти:

• Retry-After, повернений сервером
• Випадковий джитер заважає одночасному відновленню кількох завдань
• Загальні дедлайни
• Паралельна гранична величина

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

Типи помилок відповідають різним діям

Збереження логічних завдань і журналів спроб

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

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

📊 Порівняння ядра

Стабільність досвіду перекладу походить від чітких пояснень

Під час підключення до OmniDoc фронтенд повинен чітко інформувати користувачів про поточний статус: чи вони чекають, потребують повторної авторизації або чи потрібно перевірити свій акаунт. Не показуйте всі ситуації як «генеруючі».

Користувачі готові чекати на визначене, але не готові постійно натискати кнопку, яка не дає зворотного зв'язку.

Джерела: Python enum.

🎯 Який метод тобі підходить?

Якщо ви чекаєте, коли сервіс відновиться

Використовуйте обмежений відступ, встановіть максимальну кількість і загальний час очікування, а також поважайтеRetry-After сервера.

Якщо виникнуть проблеми з дозволом або обліковим записом

Припиніть автоматичну повторну спробу, запропонуйте користувачів повторити авторизацію або перевірити статус акаунта.

Якщо структура вхідного файлу неправильна

Просіть користувачів відновити файли перед відправленням і не надсилайте той самий файл повторно.

Якщо інтерфейс, який ви викликаєте, є POST і може бути обмежений час,

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

❓ Поширені запитання (FAQ)

1. Чи можна всі помилки повторити безпосередньо?

Ні, не можна. Помилки дозволу, переплати за рахунок рахунку, пошкоджені файли та тимчасова завантаженість сервісу слід розглядати окремо; лише тимчасові збої підходять для обмеженого уникнення.

2. Чи можу я повторно опублікувати після закінчення тайм-ауту POST?

Не рекомендується повторно публікувати напряму. Відсутність відповіді клієнта не означає, що сервер не створив завдання. Без ключів ідемпотентності або механізмів запитів завдань можуть виникати дублювання завдань.

3. Як слід визначати кількість повторних спроб і час очікування?

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

4. Чи вплине кількість спроб на статистику запитів користувачів?

Ні, просто запишіть одну користувацьку операцію як логічну задачу і кожну повторну спробу як спробу під цією задачею.

📝 Резюме

Ключ до повторної спроби — не пробувати кілька разів, а спочатку визначити тип невдачі, перш ніж вирішити, що робити. Відновлювані помилки обмежуються та перевіряються, а питання, що потребують людської обробки, швидко повертаються користувачам.

Досвід зараз: завантажте документ, щоб почати переклад, зберігаючи оригінальне форматування