Enhance Info Endpoints to Display Feature Flag Status
ADR/Issue Template
Enhance Info Endpoints to Display Feature Flag Status
Status
-
Proposed -
Trialing -
Under review -
Approved -
Retired
Context & Scope
We frequently use the info endpoint as the first point of insight into a service’s state when diagnosing issues. Currently, the info endpoint provides details about the build, Git commit, and connected services:
{
"groupId": "org.opengroup.osdu.indexer",
"artifactId": "indexer-gc",
"version": "0.29.0-SNAPSHOT",
"buildTime": "2025-03-20T09:02:05.159Z",
"branch": "master",
"commitId": "1f87d4500d75286ffa0485e1a440ade47365cbd8",
"commitMessage": "Merge branch 'fix-int-test-ordering' into 'master'",
"connectedOuterServices": [
{
"name": "Redis-RedisCacheBuilder$2",
"version": "7.2.7"
},
{
"name": "Redis-RedisCacheBuilder$2",
"version": "7.2.7"
},
{
"name": "Redis-RedisCacheBuilder$2",
"version": "7.2.7"
},
{
"name": "ElasticSearch-osdu",
"version": "8.15.3"
},
{
"name": "ElasticSearch-second",
"version": "8.15.3"
}
]
}
This information is insufficient when troubleshooting issues related to features controlled via Feature Flags. Challenges in Diagnosing Feature Flag Issues:
To determine the current Feature Flag state, one must:
- Identify which strategy is used—property-based or partition-based. This requires checking environment variables or reviewing the source code, e.g. https://community.opengroup.org/osdu/platform/system/storage/-/blob/master/storage-core-plus/src/main/resources/application.properties#L66
- If property-based, locate the flag within configuration properties and verify whether it is overridden by environment variables.
- If partition-based, manually request the Feature Flag state for each partition being debugged.
- Different services implement Feature Flagging in different ways, adding further complexity to debugging.
Decision
Add info about feature flag states to the info endpoint response, it might look like this:
{
"groupId": "org.opengroup.osdu.indexer",
"artifactId": "indexer-gc",
"version": "0.29.0-SNAPSHOT",
"buildTime": "2025-03-20T09:02:05.159Z",
"branch": "master",
"commitId": "1f87d4500d75286ffa0485e1a440ade47365cbd8",
"commitMessage": "Merge branch 'fix-int-test-ordering' into 'master'",
"connectedOuterServices": [
{
"name": "Redis-RedisCacheBuilder$2",
"version": "7.2.7"
},
{
"name": "Redis-RedisCacheBuilder$2",
"version": "7.2.7"
},
{
"name": "Redis-RedisCacheBuilder$2",
"version": "7.2.7"
},
{
"name": "ElasticSearch-osdu",
"version": "8.15.3"
},
{
"name": "ElasticSearch-second",
"version": "8.15.3"
}
],
"featureFlagState": [
{
"name": "collaborations-enabled",
"enabled": true,
"partition": "osdu",
"source": "appProperty"
},
{
"name": "feature.replay.enabled",
"enabled": false,
"partition": "osdu",
"source": "appProperty"
}
]
}
Rationale
Feature flag states added to the info endpoint will ease the routine maintenance of a platform, and reduce time spent on fixing issues and debugging.
Consequences
-
Update VersionInfoBuilder and IFeatureFlagInterface in the Core-Common library to include information about the feature flag state in the response.
-
Update services that use feature flags to display the state in their output. If a service uses a custom feature flag service, it should still provide feature flag information in the info endpoint response.
-
Update integration tests to verify that existing feature flags are present in the response.
-
Update the feature flag introduction policy, making it mandatory to include feature flag verification in integration and acceptance tests. https://osdu.projects.opengroup.org/pmc/work-products/pmc-portal/pmc-policies/main/projects/feature-flag.html