Why is there no guarantee that a provider event will be emitted after flag values have changed?

[man85]

I noticed that after many incorrect JSON flag data there was no client.onProviderError.
The reason is here. Is it possible for the provider to send an event for every new flag data?

Additionally,FlagStore may ignore sending events if its queue is full. Is this behavior intentional, and is it possible to fix it?

I need the provider to emit an event after the data has been sent to it for next task.

I need to pass only validated flags to the app, but flags can only be validated after they come into a provider.
I decided to create providers with checked and unchecked domains. Once flags come into the unchecked domain, validation should be performed; if it succeeds, flags are passed into the checked domain.
However, to avoid deadlocks or race conditions, an event should be emitted every time flags are passed to the unchecked domain, but currently, it isn't.

Could you fix this? Or I can try and make a PR?

[aepfli]

hey @man85,

Thank you for reaching out, and trying to move this project forward. Your input is highly valuable. Just to be sure, we are not in xy-problem area, can you shortly explain the why? - aka why you want to do this, the whole use case, and not the implementation. Maybe there is another solution, or we do have another way of solving this. ;) I just want to ensure, we are working into the right direction.

Generally we are always open for ideas, suggestions improvements, but we always need to be careful, because our implementation is not just Java, we are supporting a lot of different languages and they should be consistent. Maybe it helps looking at our provider specification. Maybe the solution is already hidden within it, maybe it shows the best way to add it.

For now, I am just trying to grasp the use case, to make an educated suggestion ;) - Based on what I am reading, I feel like this sounds like a reasonable addition. Maybe we add another error code with flagd, which shows a wonky configuration, and emits the error anyways, or maybe we do need to rethink the structure a little bit more. But first we should align on the specific use case/problem and adapt the the documentation.

Thank you for your support and engagement and reporting all those inconsistencies/inconveniences.

[man85]

the whole use case

Our feature flags are deployed to a Kubernetes ConfigMap. From there, they are continuously passed to the FlagdProvider connector using the InProcessResolver. We have a validation step to ensure all used flags can be read from the provider.
We would like to reject any flagd configuration that fails validation and remain on the previous working version, while providing information on which configuration was discarded and which is currently in use. If the flagd configuration passes validation, we apply it.

What is the best way to achieve this?

[aepfli]

I am currently unsure if I understood your setup correctly.

You have a ConfigMap and use the FlagdProvider. Do you have a flagd sidecar running, or do you map the configmap as file?

Flagd as a sidecar would actually do the thing you are asking, incorrect configurations would be ignored, and only valid configurations would trigger an update within flagd, which would inform all the consumers via grpc (also in_process).

Can you shortly outline your architecture, especially if you do have a flagd running, or do you use file mode? or how is your stack interacting with each other.

[man85]

Can you shortly outline your architecture, especially if you do have a flagd running, or do you use file mode? or how is your stack interacting with each other.

We don't have a flagd sidecar running. We have an app in k8s along with ConfigMap with flagd. The app reads ConfigMap and passes it to its own QueueSource. flagd config is not shared with other apps.