floydspace
Secrets Manager `ConfigProvider`?
Would there be interest in implementing a ConfigProvider with Secrets Manager as a backend?
Things like Lambdas could really benefit from this, enabling secure retrieval of config secrets like a DB URI.
@dudeofawesome oh yes, I was thinking about it, don't have a use case yet in my project however. And would be also cool having such provider for parameter store too
@dudeofawesome any ideas how to name the package?
I have @effect-aws/config in mind, but it could be confusing
@effect-aws/config-provider also sounds good, which would be my preference
Hmm, I was kinda thinking it would live in the same package as the client (although, I'm not sure how that would work with codegen?) If you wanted to use a separate package, I also think having "provider" in the name makes sense, although I'd suggest either pluralizing it ("config-providers") since there's potential for more than one, or putting "secrets-manager" in the name as well.
Hey @dudeofawesome
I decided to use @effect-aws/secrets-manager name (similar to @effect-aws/lambda and @effect-aws/client-lambda naming pair), so it incapsulates all possible utilities for secrets manager
the v1.0.0 is released
Awesome! Excited to see this brought in to the package set.
It looks like there's a bug regarding default values.
If I specify a secret that doesn't exist, with a default value to fall back to, I would expect it to search for the secret, not find it, and allow the default value to be used instead.
Instead, I'm seeing an error being thrown when the secret isn't found.
Here's a repro of the issue: https://effect.website/play#3b7f6e22fc22 You can switch out the provided config provider with the other sample ones to see the expected behavior.
I actually ran in to this issue myself when I was working on my own implementation of this provider. You can see some discussion of it in the Discord here.
It looks like the issue is likely due to (what I find to be) unexpected interaction between certain types of ConfigErrors & withDefault.
You can see in this playground how failing with ConfigError.InvalidData causes the error to bubble, while failing with ConfigError.MissingData allows the default value to be used.
@dudeofawesome thanks for the feedback, I will write some additional tests cases. I think it makes sense allow default values only on MissingData error.
Is your implementation somehow looks like mine?
Yeah, my implementation and yours look pretty similar, although mine was more of a quick prototype. I'd meant to make it into a PR, but you beat me to it haha.
I'm a bit of a noob with Effect, so I'd be curious to hear more of your thoughts about the default / ConfigError interaction. To me, with both of us having separately made the same assumption that all types of ConfigError allowing for default fallback, it seems like the current behavior maybe needs to be looked at. It just seems odd to effectively have to lie about the type of error that was raised.