AEM Cloud sites configuration properties merging from config.publish to config.publish.stage

Hi ​@sravs, this is expected behavior, not a bug.

AEM Cloud Service runmode resolution is winner-takes-all at the folder level, no property-level merging happens. The most specific matching folder wins entirely for that PID.

Correct pattern: Define all properties in config.publish as your baseline. In config.publish.dev, only override what differs. Any property missing from the winning folder falls back to the OSGi component’s @Designate defaults, not the parent runmode folder.

You can confirm which config “won” via /system/console/configMgr or the Cloud Manager Developer Console for publish tier.

Hi ​@akhil_merupula,

Thanks for your reply.

It appears that any property not explicitly defined under config.publish.dev is being inherited from config.publish. I have verified this in the developer console configuration, where the effective configuration reflects a combination of values from both config.publish.dev and config.publish.

If this inheritance behavior is the intended default behavior, could you please share any relevant documentation or official reference that describes it? Having such documentation would be helpful for validation and future reference.

Thanks.

Hi ​@sravs,

Can you please check both config.publish and config.publish.dev  and check the actual node/file type for that PID in each. If one is .config and the other is .cfg.json, that mismatch is worth eliminating — standardize both to .cfg.json (the current recommended format) and redeploy to see if the resolution becomes consistent.

Also verify verify there isn't a duplicate PID node elsewhere (e.g. /apps/<other-app>/config.publish.dev) also targeting the same PID, since AEM resolves by PID globally across /apps, not per-package.

Thanks,

Chitra

Hi ​@sravs ,
Please check the following:

Open /system/console/osgi-installer, search for the PID, and verify whether only one config resource is active or if multiple resources are listed. According to the documentation, only config.publish.dev should be in the Installed state, while config.publish should be in the Ignored state. Also, only two resources with the same PID should be listed. If there are additional resources, they might be stale configurations. If that’s the case, get rid of the stale ones.

If only config.publish.dev is in the Installed state, go to /system/console/configMgr, search for the PID, and check whether the extra property is shown as a configured value or as the default value defined in the configuration interface (which could indicate a code defect). You can also add logs if you suspect it is a code issue.

You may also consider opening an Adobe Support ticket, as this could potentially be a product defect.

Thanks.