I have a scenario where multiple integration flows (e.g., listening to JMS queues) are created during app runtime via IntegrationFlowContext and it works fine (SpringBoot 3.4.0), however we noticed the following situation:
Our current implementation does the integration flows registration in a method with @PostConstruct annotation. Issue is: when starting the application and there are pending messages in the JMS queues, the flows created dynamically will start processing them as expected but if any error is raised (e.g., RuntimeException) during the processing the default error handling is not called so no logs and the failure messages are lost - I'm setting the errorChannel in the JMS adapter (also checked in DEBUG mode). Looks like the error handling flow is not ready somehow during app start up (lifecycle?).
Notice that if the application is up and running and we push the same messages into the queue the default error handling flow works just fine.
We found a solution using @EventListener(ApplicationReadyEvent.class) Spring annotation instead of @PostConstruct. But is this the correct approach? Why the @PostConstruct approach does not work in this case?
Indeed the @PostConstruct is too early to start processing data.
That (auto-startup) has to be postponed until the later phase of the ApplicationContext. We even mention that in docs: https://docs.spring.io/spring-integration/reference/overview.html#programming-considerations.
That's @EventListener(ApplicationReadyEvent.class) is the right choice. At least for now.
We may look into the IntegrationFlowContext improvement to delay starts for those dynamically added flow when ApplicationContext is not ready yet.
Feel free to raise a GH issue for Spring Integration project.