Skip to content

feat: add ETag/caching support in OFREP#1854

Draft
toddbaert wants to merge 6 commits intomainfrom
feat/ofrep-caching
Draft

feat: add ETag/caching support in OFREP#1854
toddbaert wants to merge 6 commits intomainfrom
feat/ofrep-caching

Conversation

@toddbaert
Copy link
Member

@toddbaert toddbaert commented Jan 27, 2026

Implement caching in bulk evaluations as per OFREP spec.

See: https://openfeature.dev/docs/reference/other-technologies/ofrep/openapi

This is a requirement for deprecating the flagd-web-provider, as without it, polling would be substantially more expensive.

Relates to: open-feature/js-sdk-contrib#1459

@toddbaert toddbaert requested review from a team as code owners January 27, 2026 20:37
@dosubot dosubot bot added the size:L This PR changes 100-499 lines, ignoring generated files. label Jan 27, 2026
@netlify
Copy link

netlify bot commented Jan 27, 2026

Deploy Preview for polite-licorice-3db33c canceled.

Name Link
🔨 Latest commit ae50fdb
🔍 Latest deploy log https://app.netlify.com/projects/polite-licorice-3db33c/deploys/697921f6d7f4c100082db7c3

@netlify
Copy link

netlify bot commented Jan 27, 2026

Deploy Preview for polite-licorice-3db33c ready!

Name Link
🔨 Latest commit 73f07a4
🔍 Latest deploy log https://app.netlify.com/projects/polite-licorice-3db33c/deploys/697bb94e399f0e000791c808
😎 Deploy Preview https://deploy-preview-1854--polite-licorice-3db33c.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @toddbaert, 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 introduces robust caching capabilities to the OFREP bulk evaluation endpoint by implementing HTTP ETag support. This enhancement significantly optimizes performance for clients, particularly those using polling mechanisms, by preventing redundant data transfers when flag configurations remain unchanged. It's a critical step towards deprecating the flagd-web-provider by ensuring efficient data handling.

Highlights

  • ETag/Caching Support for OFREP Bulk Evaluations: Implemented ETag-based caching for bulk evaluation responses in the OpenFeature Remote Evaluation Protocol (OFREP) service. This allows clients to cache responses and receive 304 Not Modified status codes if the content has not changed, reducing network traffic and improving performance.
  • New HTTP Header Constants: Introduced new constants for HTTP headers such as ETag, If-None-Match, Content-Type, and application/json to standardize their usage.
  • ETag Calculation Logic: Added a calculateETag helper function that computes a SHA256 hash of the JSON response body to generate a unique ETag for each bulk evaluation response.
  • Bulk Evaluation Response Handling: Refactored the HandleBulkEvaluation method to utilize a new writeBulkEvaluationResponse function, which encapsulates the ETag generation, If-None-Match header validation, and conditional response sending (either 200 OK with content or 304 Not Modified).
  • Comprehensive Unit Tests: Added extensive unit tests for the new ETag functionality, covering scenarios for writeBulkEvaluationResponse (no If-None-Match, matching ETag, non-matching ETag) and calculateETag (valid response, empty response, deterministic output).
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 adds ETag-based caching to the OFREP bulk evaluation endpoint, which is a great feature for improving performance and reducing server load. The implementation is solid and includes good test coverage. I've provided a few suggestions to further improve performance by avoiding redundant JSON marshaling and to enhance logging by using structured fields, which will improve maintainability.

}

// calculateETag generates an ETag from the bulk evaluation response
func calculateETag(response ofrep.BulkEvaluationResponse) (string, []byte, error) {
Copy link
Member

Choose a reason for hiding this comment

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

Q: For the ETag calculation the flags must be in the same order every time, is this guaranteed?

Copy link
Member Author

Choose a reason for hiding this comment

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

Great point!

Ordering in maps in Go is intentionally non-deterministic so that devs cannot rely on it, but the JSON marshalling in Go does sort them:

https://github.com/golang/go/blob/master/src/encoding/json/encode.go#L183-L189

So we can rely on that.

Copy link
Member

Choose a reason for hiding this comment

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

Okay good to know, thank you!

Copy link
Member Author

Choose a reason for hiding this comment

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

TIL as well (the json marshall ordering bit). I know maps were purposely random in Go, so I was quite scared for a second.

Copy link
Member

@erka erka left a comment

Choose a reason for hiding this comment

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

Overall it looks great. I’m not sure whether SHA-256 is really required here, and it could add extra CPU load. SHA-1 or xxHash might be just as good for this use case.

@toddbaert
Copy link
Member Author

Overall it looks great. I’m not sure whether SHA-256 is really required here, and it could add extra CPU load. SHA-1 or xxHash might be just as good for this use case.

I went back and forth on this as well. SHA-1 was my first thought. It's not spec'd or anything so we could change it later... I will go back to sha1 and save some CPU cycles.

@toddbaert
Copy link
Member Author

Overall it looks great. I’m not sure whether SHA-256 is really required here, and it could add extra CPU load. SHA-1 or xxHash might be just as good for this use case.

I went back and forth on this as well. SHA-1 was my first thought. It's not spec'd or anything so we could change it later... I will go back to sha1 and save some CPU cycles.

Did this and also added some minor docs.

toddbaert and others added 6 commits January 29, 2026 14:47
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
Co-authored-by: Roman Dmytrenko <rdmytrenko@gmail.com>
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
@sonarqubecloud
Copy link

@toddbaert toddbaert marked this pull request as draft January 30, 2026 14:07
@toddbaert
Copy link
Member Author

Hey @erka @jonathannorris @jonathannorris @leakonvalinka If you have time, take a look at this alternative, which does something more like @jonathannorris suggested: #1858

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

Labels

size:L This PR changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants