Skip to content

Conversation

@kylejuliandev
Copy link
Contributor

This PR

Fixes an issue with the Flagd Provider not mapping Flag Metadata when using the RpcResolver. It looks like this was missed during the initial implementation, or it wasn't available at the time. Now metadata will be mapped for all types of flags when using the RpcResolver. Only strings, booleans, and numbers (integer/float/double) metadata types are supported - the rest are ignored.

Related Issues

Fixes #521

Notes

Follow-up Tasks

How to test

Signed-off-by: Kyle Julian <38759683+kylejuliandev@users.noreply.github.com>
@kylejuliandev kylejuliandev added the provider:flagd Issues related to provider flagd label Jan 23, 2026
@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @kylejuliandev, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a previously unaddressed issue in the Flagd Provider where flag metadata, although available from the Flagd service via RPC, was not being properly extracted and included in the ResolutionDetails object. By introducing a dedicated metadata parsing utility and integrating it into all flag resolution paths, this change ensures that the provider now fully adheres to the OpenFeature specification regarding flag metadata, offering a more complete and compliant flag evaluation experience.

Highlights

  • Metadata Mapping for RpcResolver: The RpcResolver now correctly maps flag metadata from Flagd RPC responses to ResolutionDetails for all flag types (boolean, string, integer, double, and structure).
  • New Metadata Parsing Logic: A new private helper method, BuildFlagMetadata, has been introduced to parse the gRPC Struct metadata, specifically handling string, boolean, and number types as per the OpenFeature specification, while ignoring unsupported types.
  • Comprehensive Unit Testing: New unit tests have been added to RpcResolverTests to ensure that flag metadata is accurately captured and processed across all resolution methods, including verification of supported and unsupported metadata types.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request fixes a bug where flag metadata was not being mapped when using the RpcResolver. The changes correctly add metadata mapping to all flag resolution methods (ResolveBooleanValueAsync, ResolveStringValueAsync, etc.) by introducing a BuildFlagMetadata helper method. This new method processes the metadata from the gRPC response, supporting string, boolean, and number types while ignoring others, as described.

The implementation is solid and is accompanied by a comprehensive set of tests that verify the new functionality across all supported flag types and metadata value types.

I've provided a couple of suggestions to improve code consistency and test readability. Overall, this is a great contribution that addresses an important gap in functionality.

Signed-off-by: Kyle Julian <38759683+kylejuliandev@users.noreply.github.com>
@kylejuliandev kylejuliandev marked this pull request as ready for review January 24, 2026 00:13
@kylejuliandev kylejuliandev requested review from a team as code owners January 24, 2026 00:13
Copy link
Member

@askpt askpt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very minor comment. Just a nitpick

Signed-off-by: Kyle Julian <38759683+kylejuliandev@users.noreply.github.com>

[Theory]
[MemberData(nameof(ResolveValueFlagdMetadata))]
internal async Task ResolveValueAsync_AddsFlagMetadata<T>(Func<RpcResolver, Task<ResolutionDetails<T>>> act,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thought: I wonder if the tests would be cleaner and more understandable if I separated them out into ResolveStringValueAsync and ResolveBooleanValueAsync which all check the flag metadata is added?

I think the test theory is nice but probably makes it hard to follow. Thoughts?

}
}

return items.Count > 0 ? new ImmutableMetadata(items) : null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to return null, or an empty Metadata object?

{ "key3", Google.Protobuf.WellKnownTypes.Value.ForBool(true) },
{ "key4", Google.Protobuf.WellKnownTypes.Value.ForBool(false) },
{ "key5", Google.Protobuf.WellKnownTypes.Value.ForNumber(1) },
{ "key6", Google.Protobuf.WellKnownTypes.Value.ForNumber(3.14) },
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also add a test case for a really large number

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

provider:flagd Issues related to provider flagd

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG - flagd] Flag Metadata not working (empty)

5 participants