Docs: Document that getAppConfig can only be reused for the same AppConfig application & environment

[HaaLeo]

What were you searching in the docs?

Subsequent calls to getAppConfig for different applications/environments fail. Looking at its implementation it make sense because the environment as well as the application arguments are cached.

Therefore, something like this fails with some unintuitive "ConfigurationNotFound" error:

import { getAppConfig } from '@aws-lambda-powertools/parameters/appconfig';

// This works just fine
let config = await getAppConfig('config1', {
    environment: 'first',
    application: 'myApp',
    transform: 'json'
});
console.log(config);

// This will throw an error
config = await getAppConfig('config2', {
    environment: 'second',
    application: 'myApp',
    transform: 'json'
});
console.log(config);

Is this related to an existing documentation section?

https://docs.powertools.aws.dev/lambda/typescript/latest/utilities/parameters/#fetching-app-configurations

How can we improve?

Just state that the applications/environment arguments are cached and one has to go with the AppConfigProvider class if one wants to fetch multiple configurations from multiple apps/environments within the same lambda function.

Got a suggestion in mind?

N/A

Acknowledgment

• I understand the final update might be different from my proposed suggestion, or refused.

[dreamorosi]

Hi @HaaLeo, thank you for bringing this up.

This is indeed the case, but just to understand better - in which context would you have two app/environment combinations in the same function?

If I remember correctly we implemented it this way because when it comes to AppConfig the idea is to group all the configurations for the same app and environment combinations in the same config entity.

[HaaLeo]

Hi @dreamorosi, thx for the swift reply. In our setup each service defines its appconfig configuration. In our CI/CD pipeline multiple services can be deployed at the same time. As stated here one can only deploy one config to one appconfig environment at the same time. In our setup this would lead to conflicts during deployment. Therefore, as a workaround we introduced one environment per stage per service.

That being said we now have a single lambda function acts as single entrypoint / router. This lambda now checks which services' features are en-/disabled to route the request correctly or drop it otherwise. So this lambda function needs to check different appconfig environments.

So I understand that this is rather a uncommon design. That's also why I created this as a documentation enhancement rather than a bug/feature-request.

[dreamorosi]

I see, thank you for explaining.

I think it's somewhat an edge case and perhaps there's an opportunity to review the AppConfig topology (let us know if you'd like to talk about that in a call), but I also it doesn't hurt to add a callout to the docs.

I am going to open a PR to add this

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

This issue is now closed. Please be mindful that future comments are hard for our team to see.

If you need more assistance, please either tag a team member or open a new issue that references this one.

If you wish to keep having a conversation with other community members under this issue feel free to do so.

[github-actions]

This is now released under v2.18.0 version!