Spring boot starter behavior changes on app startup

Community Support
1

Hi Temporal team, have a question regarding something we recently saw in our application. So we have a spring boot based app which interacts with temporal. The version of temporal SDK we were using was old, and we moved to the latest available version 1.23.2… When we were bringing up the app earlier on the older version (1.21.2), the app used to start, but it would keep saying that is was unable to connect to temporal if the temporal server was unavailable, which is expected… in the newer version, the app startup itself fails… we wanted to know if this is a new change and is expected?

Screenshot 2024-05-24 at 12.16.16 PM
Screenshot 2024-05-24 at 12.16.16 PM2444×212 62.4 KB

Screenshot 2024-05-24 at 12.10.39 PM
Screenshot 2024-05-24 at 12.10.39 PM2444×212 59.2 KB

By the way, on the latest version, once the Spring app starts, and we shut down the temporal server, thats fine… the app just keeps on polling and doesnt fail and resumes when the server is back up… but it is the change in app startup behavior am more curious about.

UPDATE: going through the releases, the first release this behavior happens in 1.22.0… As soon as I change the version from 1.21.2 → 1.22.0, my app startup fails if temporal is down.

2

I believe this is the change (part of 1.22) that you are witnessing: Use Spring Boot ApplicationReadyEvent to start workers · Issue #1837 · temporalio/sdk-java · GitHub

3

Thanks @maxim … is it possible to find out whether this behavior is expected? temporal being down shouldn’t cause the spring app to not start right?

4

Most users prefer the worker process not to start if the service is not reachable. The process is usually restarted by the underlying system, like K8s. This way, they can get alarmed about connectivity issues much faster.

5

Although I agree with failing fast and getting alerted about the connectivity issues much faster @maxim , is this something can be made configurable and exposed as a config override? It can default to this new behavior, but for users who preferred old behavior they can easily override the config to go back to old behavior.

6

Please file a GitHub issue with your request.