Получатель MCData промолчал: отложенная загрузка и явный отказ — разные исходы
Увеличить схему
Отправитель MCData не получил согласия на скачивание файла и считает, что адресат отказался. Но в варианте без mandatory download предусмотрен и другой результат: получатель может отложить загрузку, не отвечая немедленно. Явный отказ, отсутствие ответа и успешное принятие нужно различать. Иначе интерфейс превращает неопределённое ожидание в несуществующее действие пользователя.
Возможные действия получателя
В рассматриваемой процедуре получатель может принять загрузку, отложить её без ответа либо отказаться. Документ приводит удаление уведомления как возможный пример отказа. Конкретное действие интерфейса зависит от реализации; нельзя считать любое закрытое окно универсальным протокольным отказом.
Отсутствие ответа также не является доказательством, что сотрудник увидел предложение и сознательно решил ждать. С точки зрения отправителя это прежде всего отсутствие соответствующего подтверждения. Реальную причину определяют доступные события и правила продукта.
Как учитывать ожидание
Для отложенной доставки могут применяться временное хранение и срок доступности. Поэтому состояние «пока не скачано» не следует держать бесконечно без учёта действующей политики. По истечении срока объект может стать недоступным, и это отличается от отказа получателя.
Полезно сохранить в модели отдельные состояния: приглашение отправлено, согласие получено, отказ получен, ответа нет, содержимое недоступно. Это рекомендация по точности учёта. Она помогает оператору понять, какое дальнейшее действие предусмотрено рабочим процессом.
Проверка клиента
В тесте последовательно воспроизводят принятие, предусмотренное откладывание и явный отказ. Для каждого сопоставляют действие пользователя, фактически отправленное сообщение и результат на стороне инициатора. Затем проверяют доступность отложенного объекта до и после настроенной временной границы.
Если программа использует собственный таймаут интерфейса, его не следует автоматически показывать как отказ адресата. В отчёте указывают источник каждого перехода: пользовательское действие, ответ системы или локальное окончание ожидания.
Отдельно подтверждают скачивание после последующего согласия. Появление приглашения или его сохранение в списке не доказывает наличие содержимого файла на устройстве.
Такая проверка позволяет сохранить смысл выбора получателя. Non-mandatory режим предусматривает участие пользователя, но молчание нельзя превращать ни в согласие, ни в документированный отказ без оснований. Для диспетчерской работы важна точная история событий: она показывает фактический результат и позволяет продолжить обслуживание по правилам проекта, сохраняя различие между ожиданием и окончательным решением.
Запросы отправляются на наш e-mail из вашей почтовой программы.
