Include additional configuration information about feature stores in the status endpoint

[mbertrand80]

Is your feature request related to a problem? Please describe.
In our setup, we're using the proxy & sdk in daemon mode with Redis as the shared feature store. When initially setting it up, we noticed that flag values for one of our environments were copied into the incorrect prefix store. Attempting to troubleshoot we were unable to verify which redis host + prefix was being mapped to which environments. In the end, we just redeployed the service in our docker environment and the keys in Redis were synced with the correct environments. We're still not entirely sure if this was a deployment with incorrect information, or if something else happened.

Describe the solution you'd like
Having the non-secret bits of the feature store information available in the status endpoint would make this easier to troubleshoot. Specifically, per environment configured:

• What feature store is configured
• Whatever non-secret connection information is available for that feature store: ie. host, prefix, ttl for Redis; table name, ttl for Dynamo etc.

Perhaps including this same information in the flag store itself would also be useful to verify. Some kind of top level "storeinfo" kind of thing that had this same information.

This information is in the logs on startup, but in our environment, log retention is only a few days and we've had this instance up for a while for testing.

[bwoskow-ld]

Hi @mbertrand80!

Thanks for the feedback. I added this feature request to our backlog.

Filed internally as 91233.

[eli-darkly]

@mbertrand80, we're including support for this in the Relay Proxy 6.0.0 release which should be happening very soon.

I just wanted to mention one thing that might or might not matter to you: the way we've implemented it in this release does not quite include all non-secret database-released parameters as you suggested— specifically it doesn't include the cache TTL setting.

Our rationale was that that is not really in the category of "connection information"; it is irrelevant for any client who is reading flags from the database ("daemon mode"), because Relay's cache TTL only applies when Relay is reading flags from the database, which it would only do when clients request flags from Relay by HTTP. We were assuming that the primary use case for this new status information is to ensure that clients have the right database parameters— Redis host and prefix, DynamoDB table name, etc. We felt that including the TTL there would be potentially confusing, because that parameter has absolutely no effect on clients who are accessing the database directly and there is no reason clients would need to set their own cache TTLs to match Relay's.

It's possible that you also had some other diagnostic use in mind and that you would want to be able to see what Relay's cache TTL is for other reasons. If so, we could consider adding this in a follow-up release.

[eli-darkly]

The 6.0.0 release is now available!