Included profiles are not loaded anymore

Hello Spring Cloud Config team,

we have a question regarding the behavior change introduced with PR #3023.

As far as we understand it, after this change the Spring Cloud Config Server no longer returns properties from profiles that are only included transitively via spring.profiles.include in the served configuration files.

In our setup, we have a shared config repository with:

• one default profile
• five environment-specific profiles
• additional included profiles

Our clients usually request a config name such as default-config or default-config-camunda-7.22, together with profiles like default,<environment>.

Client side:

spring:
  application:
    name: dokument-verwaltung
  cloud:
    config:
      username: ${BASIC_AUTH_USER_NAME}
      password: ${BASIC_AUTH_USER_PASSWORD}
      profile: default,${ENVIRONMENT}
      fail-fast: true
      name: default-config-camunda-7.22
  config:
    import: configserver:${SPRING_CLOUD_CONFIG_URI}

Server side or cloud-config (git-repo)

for the profile default-config-camunda-7.22.yml

spring:
  cloud:
    config:
      allow-override: true
      override-none: true
  profiles:
    include: camunda-7-22,kafka

or the application.yml from the default profle

spring:
  profiles:
    include: security,logging,swagger,urls,feign,websocket
  cloud:
    config:
      allow-override: true
      override-none: true

Previously, this worked as expected:

• the requested config file was loaded
• profiles included from there were also resolved
• and the client received the full effective configuration

After the change from PR #3023, this no longer seems to happen.
It looks like we now have to explicitly list all profiles via spring.cloud.config.profile on the client side, including profiles that were previously only activated through spring.profiles.include.

We already reported a related issue here, which has been closed:
#3186

Our question is:

Is there a supported way to restore the previous behavior — for example via a property, flag, or another configuration option — so that included/transitive profiles are resolved again by the Config Server?

Or is the new intended behavior that clients must now always explicitly provide all required profiles themselves?

If the latter is the case, could you please confirm that this is the expected long-term behavior?

Thanks in advance for the clarification.

Start by reviewing PR #3023 and the related closed issue #3186, then reproduce the profile-resolution behavior with the shown Spring Cloud Config client settings and included profiles in the Git repository. Done means establishing whether a supported option restores transitive profile loading or confirming and documenting that clients must explicitly request every profile.