[yashdotdev13]

Summary

Fix service re-registration behavior when Consul is unavailable during initial service registration or subsequent heartbeat attempts.

Changes

• Schedule TTL heartbeats even when initial service registration fails, provided heartbeat is enabled and the service has a TTL check.
• Handle ResourceAccessException during heartbeat execution so transient connection failures do not prevent subsequent heartbeat attempts.
• Handle connection failures during service re-registration and allow retries on subsequent heartbeat attempts.
• Add regression tests covering failed initial registration and heartbeat retries after connection failures.

Testing

• ConsulHeartbeatTaskTests
• ConsulServiceRegistryRegistrationTests
• Full Maven reactor tests: .\mvnw.cmd -pl spring-cloud-consul-discovery -am test
• git diff --check

All tests passed: 145 tests run, 0 failures, 0 errors, 1 skipped.

Related Issue

Fixes #774

[ryanjbaxter]

An error that happens repeatedly will be noisy by logging the stacktrace, maybe log the stacktrace at debug level?

[ryanjbaxter]

If Consul is reachable but the re-register call returns a 5xx or 403, HttpStatusCodeException still escapes from here, while a connection failure is now handled. Would catching RestClientException be more consistent?

Also, there’s no test for this path.

[ryanjbaxter]

Since spring.cloud.consul.discovery.heartbeat.reregister-service-on-failure is false by default it probably makes sense to call out in the docs that this will only works if spring.cloud.consul.discovery.heartbeat.reregister-service-on-failure=true.

[yashdotdev13]

Addressed the review feedback by handling RestClientException during re-registration, adding a regression test for re-registration failures, reducing repetitive warning-level stack traces, and documenting the opt-in configuration. The full Maven test suite passes (146 tests, 0 failures, 0 errors, 1 skipped).

[ryanjbaxter]

Could we add a test for when failFast is true? If that is true we should not retry IMO

[ryanjbaxter]

Appending e.getMessage to the warn log would be useful to at a high level see what the reason for the failure was yet not pollute the log with the stacktrace

[ryanjbaxter]

Why was this moved outside of the try?

[yashdotdev13]

The scheduling was moved outside the try-catch to ensure that heartbeat retries are still scheduled when the initial registration fails and failFast=false. Otherwise, the registration exception would prevent scheduling, leaving the service without a retry mechanism. When failFast=true, the exception is rethrown before reaching the scheduling logic, so no heartbeat retry is scheduled.