You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We always try to fetch the metadata before we reestablish a connection, during our stream listening logic.
This might be a little bit tricky, as we are always relying on the same process, and if eg. the timeline exceeds etc. the whole process breaks.
The question is how important it is to fetch this metadata, as we could theoretically also do this unary call when the channel state changes to READY, instead of always during the loop.
This would decouple our sync from the metadata, and might increase our robustness.
Another option I was thinking about is that we could deprecate this RPC entirely, and add it to the content of the sync itself... so instead of the SyncFlagsResponse just having a flagConfiguration field, it could also have a syncMetadata field (or perhaps we could rename it something more in-line with its usage, like staticContext or something)...
Currently our Context Enrichment is handled here:
java-sdk-contrib/providers/flagd/src/main/java/dev/openfeature/contrib/providers/flagd/resolver/process/storage/connector/grpc/GrpcStreamConnector.java
Lines 107 to 124 in 122119b
We always try to fetch the metadata before we reestablish a connection, during our stream listening logic.
This might be a little bit tricky, as we are always relying on the same process, and if eg. the timeline exceeds etc. the whole process breaks.
The question is how important it is to fetch this metadata, as we could theoretically also do this unary call when the channel state changes to READY, instead of always during the loop.
This would decouple our sync from the metadata, and might increase our robustness.
WDYT?
cc: @guidobrei @toddbaert @beeme1mr @alexandraoberaigner @chrfwow
The text was updated successfully, but these errors were encountered: