Как мы должны обрабатывать длительный процесс с помощью nservicebus

Насколько я могу судить, вы делаете это так, как это должно быть сделано. Конечно, вы могли бы начать отдельную сагу для обработки тайм-аутов, но я не вижу веских причин для этого.

Поскольку вы не знаете, когда транзакция/процесс завершится в сторонней системе, конечный пользователь не может быть очень чувствителен ко времени, поэтому вам не нужно очень часто запрашивать тайм-ауты. Вы даже можете подсчитать количество тайм-аутов в данных саги и увеличить временной интервал для следующего тайм-аута, чтобы свести к минимуму количество тайм-аутов. Вы также можете проверить, как долго выполняется сага, и предупредить кого-либо (вас или клиента и т. д.), если сторонняя система заняла «слишком много времени» для завершения транзакции. Вот где саги NSB действительно сияют, они действительно гибки в решении таких ситуаций.

И, конечно же, не используйте SLR для такого рода вещей, он предназначен только для повторного запуска обработчиков при возникновении прерывистой ошибки.

IMO, похоже, что ваша сага смешивает технические проблемы (опрос внешней службы, ожидание того, что что-то произойдет) с проблемами домена (желание быть уведомленным, когда это произойдет).

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

Таким образом, у саги может быть тайм-аут для всего процесса (например, чтобы проверить, что процесс завершился в течение четырех недель, или любое другое, что, по вашему мнению, является максимальным временем, которое он должен занять до всех) и просто подписаться на событие TransactionCompleted из интеграции услуга.