tenants: shut the delayed tenant provisioning down with its context

[iliyan-velichkov]

Cause

The PostgreSQL slow shard of master and the nightly has been failing with the same cascade (runs 37275439965, 37088834792, 36903920667). Every class after LocalNativeAppLifecycleIT (IntentEngineIT, ActAsSessionIT, ExternalFrontendTenantSelectionIT, ... 170 errors) fails after ~308 s with

liquibaseSystemDB: liquibase.exception.LockException: Could not acquire change log lock.
Currently locked by runnervm8df0l (10.1.0.211) since 10/5/26, 7:29 AM

TenantsInitializer scheduled the tenant provisioning 30 s after ApplicationReadyEvent on a ScheduledThreadPoolExecutor it never shut down. LocalNativeAppLifecycleIT boots one context per test method, each living about 13 s, so every one of its contexts left a provisioning timer behind. Those timers fired after their context had closed, five of them during the class, each on a pool-N-thread-1 thread. A late run goes through the closed context's beans, and Spring re-creates them on demand. The log shows a new SystemDB Hikari pool and the SystemDB Liquibase update running on that pool thread (07:28:21 [pool-13-thread-1] liquibase.changelog - Reading from public.databasechangelog). The last one fired at 07:29:25.206, 0.1 s after DirigibleCleaner had dropped and recreated the PostgreSQL system schema. The next context's Liquibase then found the changelog lock held and waited for it, and so did every class after it. On H2 the schema lives in a file under the fork's own target/, which is why only the PostgreSQL leg shows it.

The same leak exists outside tests: any context that closes within 30 s of becoming ready keeps a timer that later reaches into its closed beans.

Change

The executor is now a field of the bean and is shut down in destroy(). A provisioning that has not started when its context closes never runs. The delay is still 30 s. A package-private constructor takes the delay so the unit test does not have to wait 30 s.

Verification

• mvn -pl components/core/core-tenants test: 33/33 green, including the new TenantsInitializerTest. It checks that the provisioning runs after the delay, and that a provisioning scheduled before destroy() never runs. Mutation check: with destroy() turned into a no-op, the second test fails.
• PostgreSQL 16 locally (system DB and default DB as separate databases, as on the CI leg): -Dit.test=LocalNativeAppLifecycleIT,ActAsSessionIT -Dfailsafe.runOrder=reversealphabetical, i.e. ActAsSessionIT booting right after LocalNativeAppLifecycleIT, which is the order that fails on CI. Result: 10/10 green and BUILD SUCCESS. The log has no TenantsInitializer run after a context closed, no Liquibase on a non-main thread and no Waiting for changelog lock. For comparison, the CI log of the same class on master has five late provisioning runs.
• formatter:validate on the module, with the cache wiped.
• Not verified: the full PostgreSQL slow shard. The timing that poisons the lock depends on the runner, so the shard's next run on master is the real proof.

The other master failure, the api shards cancelled at their 90-minute cap, is unrelated and is addressed separately.

🤖 Generated with Claude Code