fix(ofrep): fix flaky rate limit test with date-based Retry-After

[josecolella]

Summary

• Fixes flaky test_ofrep_provider (3.4) CI failure that was blocking PR chore(main): release openfeature-flagsmith-provider 0.1.3 #111 (and other release PRs)
• The test used Time.now + 1 for the Retry-After header, which could expire before the assertion ran on slow CI runners
• Changed to Time.now + 60 to eliminate timing sensitivity

Test plan

• bundle exec rspec spec/openfeature/ofrep/provider/client_spec.rb:174 passes locally
• Full ofrep test suite (44 examples, 0 failures) passes locally

🤖 Jose's AI agent

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! 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 critical CI flakiness issue affecting the ofrep provider tests. The problem stemmed from a test asserting rate-limiting behavior, where a Retry-After header was set with a very short expiration time, causing the test to fail intermittently on slower CI environments. The fix involves extending this expiration period significantly, ensuring the test reliably passes by providing ample time for the assertion to complete.

Highlights

• Flaky Test Fix: Addressed a flaky test_ofrep_provider (3.4) CI failure that was blocking other pull requests.
• Root Cause Identified: The test used Time.now + 1 for the Retry-After header, which could expire prematurely on slow CI runners, leading to intermittent failures.
• Solution Implemented: Increased the Retry-After duration to Time.now + 60 seconds to eliminate timing sensitivity and ensure reliable test execution.

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.

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. ↩

[gemini-code-assist]

Code Review

This pull request fixes a flaky test by increasing the Retry-After duration. While this is a pragmatic solution that will likely resolve the immediate issue, I've added a comment with a suggestion for a more robust fix. By controlling time in the tests, you can eliminate the root cause of the flakiness and improve the overall stability of your test suite.

[gemini-code-assist]

While increasing the delay to 60 seconds makes this test less likely to fail, it doesn't fully eliminate the root cause of flakiness, which is the use of Time.now in tests. This makes the test's outcome dependent on execution speed.

A more robust approach is to control time by stubbing Time.now. This makes your time-dependent tests deterministic, faster (by avoiding sleep in other tests), and more reliable.

For example, this test could be rewritten as:

it 'blocks subsequent calls when rate limited with Retry-After header (date)' do
  start_time = Time.new(2023, 1, 1, 12, 0, 0)
  allow(Time).to receive(:now).and_return(start_time)

  stub_request(:post, 'http://localhost:8080/ofrep/v1/evaluate/flags/my_flag')
    .to_return(status: 429, headers: { 'Retry-After' => (start_time + 2).httpdate })

  expect {
    client.evaluate(flag_key: 'my_flag', evaluation_context: default_evaluation_context)
  }.to raise_error(OpenFeature::OFREP::RateLimited)

  # Advance time, but stay within the retry window
  allow(Time).to receive(:now).and_return(start_time + 1)

  expect {
    client.evaluate(flag_key: 'other_flag', evaluation_context: default_evaluation_context)
  }.to raise_error(OpenFeature::OFREP::RateLimited)
end

Applying this pattern across your time-sensitive tests would be a significant improvement to the test suite's stability and prevent future flakiness.