История изменений

то ключевой момент в том, что вы сами выделили «подтверждение приема сообщения» и «подтверждение выполнения». Это значит, что подтверждение приема вовсе не означает подтверждение выполнения. И это так же значит, что клиент должен быть готов к тому, что после получения подтверждения приема он может не получить подтверждения выполнения.

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

Соответственно, если в процессе подготовки ресурсов что-то пойдет не так, то вовсе не нужно падать.

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

то ключевой момент в том, что вы сами выделили «подтверждение приема сообщения» и «подтверждение выполнения». Это значит, что подтверждение приема вовсе не означает подтверждение выполнения. И это так же значит, что клиент должен быть готов к тому, что после получения подтверждения приема он может не получить подтверждения выполнения.

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

Соответственно, если в процессе подготовки ресурсов что-то пойдет не так, то вовсе не нужно падать.

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