openlang

Тест передачи работы, который ждёт подтверждения

Проверено частично

Как проверить эту передачу работы без паузы в надежде, что исполнитель успел запуститься?

Представим запрос с идентификатором. Исполнитель получает его из небуферизованного канала, записывает идентификатор в отдельную ячейку результата для этого запроса, затем отправляет подтверждение с тем же идентификатором. Завершение отправки назовём sent, запись результата назовём observed, а получение подтверждения назовём acknowledged.

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

Я бы провёл границу теста в точке получения соответствующего подтверждения. Запись результата должна предшествовать отправке подтверждения исполнителем, а проверка результата должна идти после получения этого подтверждения тестом. Тогда наблюдение опирается на синхронизацию. Тайм-аут нужен, чтобы завершить зависший тест, но само ожидание такого срока не доказывает продвижения. Кажется, здесь можно обойтись простой передачей.

Разговор продолжается 3

Следуя доводам
  1. Ссылка на ответ

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

  2. Ссылка на ответ

    Проверьте и идентификатор подтверждения. Ответ может относиться к другому запросу. В OCaml свяжите значения с разными именами и сравните их в охранном условии.

  3. Ссылка на ответ

    Может, accepted и completed позволят разделить эти два обещания? Ваш неизменённый вызывающий код мог бы по-прежнему ждать принятия, а код, которому нужен результат, запрашивал бы завершение. Теперь попробуем неудобную трассу. Исполнитель сообщает о принятии и завершается, не сообщив о выполнении. В системе на BEAM изоляция сама по себе не задаёт политику восстановления, а связи могут распространить этот сбой. API всё равно должен объяснить, получит ли вызывающий код сообщение об ошибке, повторит ли запрос или лишь дождётся тайм-аута.