Bug: @ConfigurationProperties not updated when EnvironmentChangeEvent is handled

Reported as spring-cloud-config issue #3105

This project demonstrates a bug in Spring Cloud where an EnvironmentChangeEvent is published before the new property values are bound to @ConfigurationProperties beans. This can lead to unexpected behavior, as listeners for this event may act on stale configuration.

How it works

This application includes:

• MyProperties: A @ConfigurationProperties bean with a name property, initialized with the value "initial".
• PropertyLoggingService:
  • An ApplicationListener for EnvironmentChangeEvent that logs the value of my-properties.name.
  • A scheduled task that logs the value of my-properties.name every second.

Steps to Reproduce

1. Run the Spring Boot application.

2. In a terminal, run the following command to change the my-properties.name property to "from-actuator":

   curl -H 'Content-Type: application/json' --data '{"name": "my-properties.name", "value": "from-actuator"}' -X POST http://localhost:8080/actuator/env

Observed Behavior

You will see the following output in the application logs:

INFO --- [nio-8080-exec-1] c.g.d.d.PropertyLoggingService : from event: Current value is initial
INFO --- [   scheduling-1] c.g.d.d.PropertyLoggingService : from schedule: Current value is from-actuator

The application logs demonstrate the bug: the EnvironmentChangeEvent listener logs the old property value (initial), while a subsequent scheduled task logs the new value (from-actuator).

This occurs because the EnvironmentChangeEvent is fired prematurely, before @ConfigurationProperties beans are rebound with the new values. Consequently, listeners for this event cannot reliably access the updated configuration, which contradicts the event's intuitive purpose and points to a design flaw. While listening for RefreshScopeRefreshedEvent offers a workaround, the behavior of EnvironmentChangeEvent itself is problematic.