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

Для одного случая найдите локальный delivery stop ID, order ID, upload ID, ключ файла в хранилище и событие завершения доставки. Проверьте tenant, курьера и время. Не прикрепляйте файл вручную только по близкой дате: связь должна подтверждаться устойчивым идентификатором операции.

Что проверить в первую очередь

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

  • Проверьте, завершилась ли загрузка файла и существует ли объект в хранилище.
  • Найдите metadata с order ID, stop ID, courier ID и idempotency key.
  • Убедитесь, что событие delivered ссылается на тот же upload ID.
  • Сравните часы устройства и сервера, состояние offline queue и последнюю синхронизацию.

Почему возникает проблема

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

  • Файл загружается до получения серверного ID и остается временным объектом.
  • Приложение очищает локальную очередь после загрузки файла, но до привязки к заказу.
  • Повтор маршрута создает новый stop ID, а доказательство остается на старом.
  • Политика доступа запрещает backend прочитать объект из другого tenant prefix.
  • Большое фото не завершает multipart upload при переходе приложения в фон.

Пошаговая диагностика

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

  • Проследите один capture ID через мобильный лог, API и object storage.
  • Проверьте незавершенные multipart uploads и объекты без записей в базе.
  • Воспроизведите сценарий с отключением сети между загрузкой и подтверждением доставки.
  • Сравните retry запросов и одинаковость idempotency key после перезапуска приложения.
  • Проверьте права доступа по tenant, заказу, маршруту и пользователю просмотра.

Как связать файл и событие доставки

Загрузка должна создавать управляемый upload resource, а завершение доставки — ссылаться на него. Сервер подтверждает принадлежность upload текущему курьеру и заказу, после чего переводит временный объект в финальное состояние.

  • Клиент заранее получает upload ID, привязанный к delivery attempt.
  • Каждая часть файла загружается повторяемо и подтверждается сервером.
  • Finalize проверяет размер, тип, контрольную сумму и владельца.
  • Событие delivered атомарно связывает финальный upload с правильным заказом.

Как исправить проблему

Исправление делите на небольшие обратимые изменения. Сначала устраните подтвержденную причину, затем повторите исходный сценарий и проверьте соседние функции. Массовое обновление данных запускайте на ограниченной выборке с отчетом и только после сверки расширяйте на весь объем. Не отключайте авторизацию, проверку сертификатов, валидацию или аудит ради быстрого исчезновения симптома.

  • Внедрите устойчивый capture or upload ID до начала отправки файла.
  • Сохраняйте offline queue до подтверждения и файла, и связи с заказом.
  • Используйте multipart resume и уменьшение изображения до разумного размера.
  • Добавьте фоновое сопоставление только по доверенным ID с карантином неоднозначных объектов.
  • Показывайте курьеру статус синхронизации и запрещайте тихое удаление неподтвержденных материалов.

Безопасный порядок внедрения

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

Как проверить результат

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

  • Фото и подпись появляются у правильного заказа после обычной и офлайн-доставки.
  • Перезапуск приложения и повтор синхронизации не создают копии.
  • Файл другого tenant или маршрута нельзя привязать подменой order ID.
  • Незавершенная загрузка остается в очереди и может безопасно продолжиться.

Типичные ошибки при исправлении

  • Сопоставлять потерянные файлы только по имени, времени или номеру телефона.
  • Удалять локальную копию сразу после HTTP 200 части загрузки.
  • Разрешать клиенту произвольно указывать владельца уже загруженного объекта.
  • Публиковать прямые постоянные ссылки на доказательства доставки.

Как предотвратить повторение

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

  • Контролируйте uploads без finalize и заказы delivered без proof.
  • Тестируйте слабую сеть, фон, перезапуск и повтор маршрута.
  • Храните аудит доступа к доказательствам и ограниченный срок подписанных URL.
  • Регулярно очищайте только подтвержденные временные объекты по безопасной политике.

Что контролировать после выпуска

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

Что подготовить для технического разбора

  • Описание ожидаемого и фактического поведения с точной последовательностью действий.
  • Время проблемы, идентификатор тестового объекта и версии затронутых компонентов.
  • Фрагменты журналов до и после ошибки без секретов и персональных данных.
  • Перечень последних изменений и уже выполненных проверок.
  • Безопасный доступ к тестовой среде либо способ воспроизвести сбой без влияния на клиентов.

Частые вопросы

Можно ли восстановить уже загруженные файлы без связи?

Да, если сохранились доверенные metadata или журналы с upload ID и delivery attempt. Неоднозначные файлы лучше отправить на ручную проверку.

Нужно ли хранить оригинал фотографии?

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

Когда нужна помощь специалиста

Если доказательства доставки теряются между приложением, API и хранилищем, я могу восстановить цепочку upload, исправить offline sync и настроить безопасную привязку к заказам.