Пользователь запустил импорт, но не знает, идет ли работа или процесс потерян. Запись «задача поставлена» не подтверждает выполнение. Фоновому процессу нужны идентичность, состояния и понятный механизм восстановления после остановки исполнителя.
Что подготовить
- Типы задач, их побочные эффекты и максимальная ожидаемая длительность.
- Очередь, способ подтверждения и правила повторной доставки.
- Нужные пользователю статусы и допустимый срок ожидания результата.
Порядок работы
- Определите состояния: ожидает, выполняется, завершено, ошибка и отменено; опишите допустимые переходы.
- Свяжите журналы и результат с устойчивым идентификатором задания, сохраняя номер попытки.
- Фиксируйте прогресс по завершенным единицам работы, если их количество известно, а не по произвольному проценту времени.
- Определите признак потерянного исполнителя и порядок повторного назначения с защитой от двойного выполнения.
- Проверьте остановку процесса в начале, середине и после сохранения результата до подтверждения очереди.
Разобранный пример
Импорт содержит тысячу строк. После подтвержденной обработки трехсот процесс остановился. Контрольная позиция и повторяемая запись позволяют продолжить с последней подтвержденной границы. Пользователь видит обработанные строки и конкретные ошибки, а не бесконечный индикатор.
Как проверить результат
- Завершенный результат можно найти по идентификатору задания.
- Повторная доставка не дублирует уже примененные изменения.
- Ошибки разделены на временные и окончательные, а число попыток ограничено.
Если что-то пошло не так
Если задача зависла, не запускайте копию без проверки активности первого исполнителя. Используйте согласованное владение и срок его действия либо иной механизм координации. После исчерпания попыток сохраняйте диагностируемое состояние и путь ручного решения.
Карточка одной попытки задания
Храните для попытки время назначения, время начала, исполнителя, последнее подтвержденное продвижение и причину завершения. Эти поля помогают отличить задачу, которая еще стоит в очереди, от задачи с потерянным исполнителем. Сам факт отсутствия новых строк журнала не доказывает зависание: операция может законно выполнять длительный неделимый этап.
Разделите идентификатор задания и номер попытки. Пользователю обычно нужен один результат задания, а оператору — история нескольких попыток. При повторе сохраняйте причины предыдущих отказов. Иначе последнее сообщение об успехе уничтожит сведения о систематической нестабильности и затруднит поиск источника задержек.
Для длительного импорта определите единицу подтверждения: строка, пакет или целый файл. Она задает объем повторной работы после остановки. Протестируйте сохранение результата непосредственно перед потерей подтверждения очереди. Если результат уже существует, повтор должен его распознать, а не создавать новый. Отмена тоже требует контракта: запрос отмены может прекратить будущие шаги, но не обязательно отменяет уже примененные изменения. Покажите это в статусе и отчете. При ручном возобновлении сохраняйте, кто и почему принял решение, и не возвращайте окончательно ошибочные данные в бесконечный цикл одинаковых попыток.
Промпт для разбора ваших материалов
Спроектируй модель состояний фонового задания. Опиши идентификаторы, попытки, прогресс и восстановление после падения. Для каждой точки остановки укажи, как исключается повторный побочный эффект.Частые вопросы
Достаточно ли строки в журнале?
Нет. Для восстановления нужно устойчивое состояние, которое можно однозначно связать с результатом и попытками.
Нужен ли процент выполнения?
Только если он основан на измеримом объеме. Иначе лучше показывать этап, обработанное количество и время последней активности.
Материал библиотеки решений Ильи Тарасова / TarasovWeb.
О проекте
Практическая библиотека Ильи Тарасова и TarasovWeb. Telegram-канал · Личная страница · ВКонтакте.
#tarasovweb #ИльяТарасов