Если интерфейс сообщает об ошибке, попробовать еще раз? Задачи документирования должны сначала определить, какие сбои можно устранить.

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

Эта статья подходит для разработчиков и студентов, изучающих продукты, которые выполняют асинхронные задачи, такие как перевод и преобразование документов. Прочитав это, вы можете сначала классифицировать сбои, а затем решить, как долго ждать, сколько максимум попыток и когда потребуется вмешательство пользователя.

Приведенный ниже код и последовательность действий основаны на синтетических образцах, протестированных в изолированной среде. Они не являются гарантией подлинности всех документов или эффектов продукта. Пожалуйста, сохраняйте оригиналы перед обработкой важных документов и просматривайте их согласно границам и пунктам приемки в тексте.

Как повторить попытку после того, как задача документа сообщает об ошибке? Вывод в одно предложение

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

Сначала определите, приведет ли повторная попытка к дублированию задач.

Тайм-ауты 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. Повлияет ли количество попыток на статистику обращений пользователей?

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

📝 Резюме

Ключ к повторным попыткам заключается не в том, чтобы пытаться больше раз, а в том, чтобы сначала определить тип неудачи, а затем решить, что делать. Неисправности, которые можно устранить, повторяются ограниченным образом, а проблемы, требующие вмешательства человека, своевременно возвращаются пользователям.

Попробуйте сейчас: загрузите документ, чтобы начать перевод, сохранив исходный макет.