AppConfig: GetLatestConfiguration does not resolve FeatureFlags profile to retrieval-time format (returns raw {flags,values,version} instead of flattened values)

What happened?

For a Configuration Profile created with Type: AWS.AppConfig.FeatureFlags, real AWS AppConfig stores content in a deployment-time format ({"flags": {...}, "values": {...}, "version": "1"}) but serves a different retrieval-time format from GetLatestConfiguration: only the contents of values, flattened to the top level (e.g. {"my_flag": {"enabled": true}}).

This is documented by AWS itself: https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-agent-how-to-use-local-development-samples.html

Retrieval-time format is the format returned when the flag is retrieved from the GetLatestConfiguration API, which only contains the flag's value. Retrieval-time format doesn't include a flag's complete definition (as passed to the CreateHostedConfigurationVersion API).

In Floci, GetLatestConfiguration returns the stored content verbatim (the deployment-time format), regardless of the profile's Type. A client relying on the documented retrieval-time format (e.g. @aws-lambda-powertools/parameters AppConfigProvider, or aws_lambda_powertools.utilities.parameters.AppConfigProvider) will see the values-wrapped structure instead of the flattened one, breaking any code that reads a flag by name directly off the top-level object.

Root cause in code

src/main/java/io/github/hectorvent/floci/services/appconfig/AppConfigDataService.java, getLatestConfiguration():

byte[] content = (version != null) ? version.getContent() : new byte[0];

The method returns version.getContent() unchanged. There is no branch on the profile's Type (AWS.AppConfig.FeatureFlags vs AWS.Freeform), and no transformation that extracts values and flattens it for FeatureFlags profiles.

Reproduction steps

I confirmed the equivalent issue against Ministack (a different emulator with the same architecture) with @aws-lambda-powertools/parameters AppConfigProvider (Node.js/TypeScript):

1. Create an Application, an Environment, and a Configuration Profile with Type: AWS.AppConfig.FeatureFlags.
2. Create a Hosted Configuration Version with Content set to {"flags":{"my_flag":{"name":"my_flag"}},"values":{"my_flag":{"enabled":true}},"version":"1"}.
3. Create a Deployment Strategy with DeploymentDurationInMinutes: 0 and start a Deployment for that version.
4. Instantiate AppConfigProvider({ application, environment, awsSdkV3Client: new AppConfigDataClient({ endpoint: "<emulator endpoint>" }) }) and call provider.get(profileId, { transform: "json" }).

I haven't run the same sequence against Floci directly, but the code path in AppConfigDataService.getLatestConfiguration() shows the identical pattern (returning the stored content unchanged, with no type-aware transformation), so I'd expect the same result. Please close this as a duplicate/not-a-bug if a manual check shows Floci already handles this correctly.

Current Behaviour (expected, based on code inspection)

{"flags":{"my_flag":{"name":"my_flag"}},"values":{"my_flag":{"enabled":true}},"version":"1"}

Expected Behaviour (matches real AWS AppConfig data plane, verified against a live AWS.AppConfig.FeatureFlags profile via GetLatestConfiguration)

{"my_flag":{"enabled":true}}

Additional context

Filed alongside the same report against Ministack, where I verified the actual runtime behavior (not just code inspection): https://github.com/ministackorg/ministack/issues/1771

Workaround used in the meantime: create the Configuration Profile without Type (defaults to Freeform) and deploy the flat/retrieval-time JSON directly, since Freeform profiles are not expected to go through the flags/values transformation.