[BUG] Global disabled=1 default combined with missing metadata export guardrail disables searches across entire Splunk environment

[GCarr230]

Describe the bug

After syncing our fork with the upstream contentctl repository (around Feb 13), a large number of reports and alerts across our entire Splunk environment were unexpectedly disabled.
Investigation suggests this was caused by a combination of two upstream changes:
A global [default] stanza was introduced in savedsearches_detections.j2 with disabled = 1, which defaults all searches to disabled
The metadata guardrail in metadata/default.meta (export = none under [savedsearches/default]) was removed
Because the metadata restriction was removed, the default disabled = 1 setting was applied globally across the Splunk environment instead of being confined to the ContentCTL app.

This resulted in:
Reports and alerts across multiple apps being disabled
Silent impact with no obvious warnings
Partial masking of the issue where some detections explicitly set disabled = 0

Expected behavior

Default search configurations should be scoped only to the ContentCTL-managed app
Metadata guardrails (export = none) should prevent configurations from impacting other apps
Upstream changes should not introduce behaviour that disables searches globally across the environment

Screenshots

N/A

contentctl Version:

v5.0.0

Additional context

Splunk logs indicate searches began disabling around Feb 12–13, aligning with when the upstream sync occurred
No merge conflicts were present during the sync
Detection alerts in our contentctl deployed app largely remained active due to explicit disabled = 0 settings
However, all other searches in all splunk apps were disabled(100+)

[ljstella]

The metadata change was added in the exact same release for new repos in the app_template directory.

Additionally, the changes were made to the existing file in the same ESCU release for folks tracking the Splunk/security_content repo.

app_template the directory does not get updated when you update contentctl- this is why we HIGHLY suggest pinning a specific version and very carefully reviewing changes between each version.

Currently, contentctl has no migrations nor version aware repo handling. This is your responsibility as a user.

[GCarr230]

Ah I see it now, thanks for clarifying. The guardrail was added to app_template, but because our app was initialised months ago, contentctl didn't (and shouldn't) overwrite our existing default.meta during the CI/CD build. So our app got the new disabled = 1 baseline from the .j2 template, but lacked the metadata guardrail to contain it, which caused the global leak across our Splunk environment. We'll make sure to pin our contentctl versions moving forward and manually patch our app's metadata.

One piece of feedback before closing this out: I highly recommend adding a prominent warning to the release notes for users upgrading existing apps. Because the penalty for missing this manual metadata update is a global Splunk alerting outage, it’s an easy trap to fall into since it fails silently during the build. Appreciate the clarification.