Hopefully this won't be necessary when using a @Bean method. If it is necessary, one scenario where the @Bean method may be called multiple times is in tests with slightly different configuration that result in the creation of multiple contexts. Removing one provider in favour of a new one may cause problems there.

I added this mostly for tests. This is needed because the Liquibase configuration providers are static and when the LiquibaseAutoConfigurationTests run, they destroy Spring context in between tests, leaving the register with a stale configuration variable. I could handle this inside each test, but I think it might be wise to keep in source for downstream consumers too. I don't think this would be an issue in production runs, but I'll lean on your experience for that.

I wonder if we could avoid the problem by sub-classing SpringLiquibase and overriding afterPropertiesSet to create a child scope before calling super. This child scope could hold the EnvironmentConfigurationValueProvider and, hopefully, remove any problems of multiple contexts interfering with each other. Our existing subclass (DataSourceClosingSpringLiquibase) would become a sub-class of the proposed new sub-class.

So if I understand correctly, your suggestion is to execute the Spring Liquibase logic within a Liquibase child scope with the new provider defined? If so, I created this subclass like this. But, in testing, what I found out is that Liquibase still registers its providers globally, even if the provider was registered to a child scope.

Ok, so I think one way it could be done is if the provider was defined by the scope(scope id passed in during construction). The provider can then request the current scope id at any point and then just return false for a lookup if its not the appropriate scope it was created with. My only thought is whether it's necessary to have this level of separation? Is it realistic that two Spring Liquibases would ever run at the same time? If it is, I could implement this, but if it's not, I'd lean to simplicity.

Having two run in parallel is unlikely, but having them run serially with potentially different configuration is definitely possible both in tests and in apps with a context hierarchy. There's also the Actuator endpoint to consider where we use StandardChangeLogHistoryService at that can be called at any time, not just during application context refresh. I haven't examined the code path of the history service to know if it references configuration values that would be affected by configuration value providers.

Sorry for the delay, finally circling back to this. I updated as you suggested. I verified that there are a few Liquibase properties(I added a test for one) that do get referenced in the endpoint, so I wrapped that as well. I verified that at least all the tests in the module are referencing the correct env through logging. It is possible for users to still do things like execute Liquibase themselves, but that's the only edge case I can think of, otherwise, that would not be wrapped currently. I added a few other comments for some other thoughts I had, like logging and fallbacks as well, that I'd love your input on.

We could add additional strategies here, such as inferring the env if there's only one, for example. I opted for the simplest solution for now, but would love input on this.

I am not aware of how scope works but can't we just put the Environment and not have a local cache here?

So that’s actually what I did originally, but @wilkinsona raised a concern around how this behaves with child Spring Boot contexts. From what I understand, the way Liquibase handles provider registration makes this tricky. Liquibase’s ConfigurationValueProvider registry is global and static, keyed only by class name, while Spring Boot’s configuration model is context-scoped.

Each Spring context can define its own properties and should override those from its parent. For example:

Parent context

spring:
  liquibase:
    properties:
      liquibase.duplicateFileMode: 'WARN'

Child context

spring:
  liquibase:
    properties:
      liquibase.duplicateFileMode: 'ERROR'

The expected Boot behavior is that the child context overrides the parent, and the parent keeps its own configuration. But because Liquibase maintains a single global provider list, all providers share the same static state. That’s the core mismatch.

Originally, I just replaced any previously registered provider when a new context started. That works fine for most cases, because Spring Boot typically initializes contexts sequentially and Liquibase itself only runs during startup. This is also the simplest and most test-friendly approach.

The edge case appears when Liquibase is accessed after startup-for example, via the Actuator Liquibase endpoint or any custom Liquibase invocation. In those cases, the provider would return values from the most recently initialized Spring context, even if the call originated from the parent context. That’s where correctness can drift.

To get ahead of your specific question: storing the Environment directly (as you suggested) works only when there’s a single context. With multiple contexts, there’s no way for Liquibase to indicate which Spring context a configuration lookup is coming from. Liquibase doesn’t expose that information. The only feasible mechanism is to pass some form of context identity through Liquibase’s Scope API, which is why the current PR uses that indirection.

And that’s really the broader issue: Liquibase assumes configuration providers are global and static, while Boot assumes configuration is hierarchical and scoped. Because those models don’t naturally align, we end up with tradeoffs.

So from what I can tell, there are a few realistic paths:

1. Don’t support overriding in child contexts, and document that limitation clearly.
2. Partially support it (current PR behavior): initialization + the Actuator endpoint work correctly, but any ad-hoc Liquibase usage might not resolve the right context. Practically speaking, those scenarios seem very rare.
3. Decide the complexity isn’t worth it and close the PR.

I’m open to whichever direction best fits Boot’s conventions. My main goal here is just to make the tradeoffs visible so we can decide on the right level of support.

I considered adding logging here if we get a request for a config from this provider but we can't infer the env but I didn't see any other logging in the module, so I skipped for now.

I am not aware of how scope works but can't we just put the Environment and not have a local cache here?

It's not supposed to be nullable. I know that ApplicationContext#getId can return null but that's an oversight, see spring-projects/spring-framework#35925

You can have two catch blocks here

I really would like that the responsability of this was in Liquibase's scope, and not here.

Please keep the original signature. Even if it's not used by the method's body, it's a breaking change.