Ну, поток сам по себе является просто логическим контейнером для компонентов, которые он соединяет. Хотя мы действительно можем каким-то образом получить доступ ко всем этим компонентам в одном IntegrationFlow, это не означает, что все ваше решение содержит только один IntegrationFlow. Соединение компонентов из разных IntegrationFlow вполне нормально, поскольку во время выполнения они полностью не связаны с созданным IntegrationFlow. Эти компоненты среды выполнения идентичны после любого анализа конфигурации, который у нас есть в структуре: XML, Java DSL, Kotlin DSL или просто Java и конфигурация аннотаций. Вы даже можете создать все bean-компоненты вручную, но во время выполнения это будет решение EIP.
Я пытаюсь сказать, что неправильно пытаться найти решение для всего состояния потока. Или вам следует проконсультироваться с каким-то отдельным компонентом (например, упомянутым RSS), или у вас должен быть какой-то отдельный компонент для отслеживания такого настраиваемого состояния.
См. Lifecycle контракт. Большая часть Spring Integration реализует его, поэтому вы можете проверить его isRunning(), когда вам нужно. Фактически, даже StandardIntegrationFlow реализует это, но вы не должны полностью полагаться на него, потому что ваше окончательное решение может состоять из нескольких потоков или многих независимых компонентов.
Нет ничего похожего на stopped with exception - мы не не останавливают компоненты из-за ошибки. Вместо этого вы можете включить метрики и проверить канал или обработчики success и failure количество отправлений: https://docs.spring.io/spring-integration/docs/5.3.0.RELEASE/reference/html/system-management.html#metrics -management