fix: flacky e2e tests

[aepfli]

Seems like we do have a race condition, where we are not entering a certain state, i assume that this might be caused by a race condition, of too many events back to back and how they are processed.

Maybe we should change the implementation of our eventing to a queue, which gets filled and taken from, to ensure events are thrown in the order they are emitted?

[gemini-code-assist]

Summary of Changes

Hello @aepfli, 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 aims to resolve flakiness in end-to-end tests by tackling a race condition identified in the handling of provider state changes. The core change involves implementing explicit waits for the provider to reach a READY state before proceeding with error or stale event emissions, thereby stabilizing test execution and ensuring proper state synchronization.

Highlights

• Race Condition Fix: Addresses a suspected race condition in end-to-end tests related to provider state transitions, which was causing flakiness.
• Explicit State Waiting: Introduces explicit waiting for the READY provider state before emitting ERROR or STALE events, ensuring that subsequent events are processed only when the provider is in the expected state.
• Refactored State Waiting Logic: Extracts the Awaitility logic into a new private static helper method, waitForProviderState, improving code readability and reusability within the test setup.

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

[gemini-code-assist]

Code Review

This pull request addresses flaky end-to-end tests by introducing explicit waits to ensure provider state transitions are processed deterministically. This is a good approach to resolving the underlying race condition. The refactoring of the wait logic into a waitForProviderState method is also a good improvement. However, I've identified a logical issue in how the FATAL provider state is tested. It is incorrectly grouped with the ERROR state, which with the new changes will cause the test for the FATAL case to fail deterministically. I've provided a suggestion to separate these cases, which should fully resolve the test flakiness and correctness issues.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.41%. Comparing base (6dcd21f) to head (8134419).
⚠️ Report is 14 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1607      +/-   ##
============================================
+ Coverage     92.06%   93.41%   +1.35%     
- Complexity      488      491       +3     
============================================
  Files            46       46              
  Lines          1184     1184              
  Branches        105      105              
============================================
+ Hits           1090     1106      +16     
+ Misses           62       48      -14     
+ Partials         32       30       -2     

Flag	Coverage Δ
unittests	93.41% <ø> (+1.35%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[chrfwow]

Maybe we should change the implementation of our eventing to a queue, which gets filled and taken from, to ensure events are thrown in the order they are emitted?

Might be a good idea, we don't want to miss state changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[aepfli]

superseded by #1628 - the fix and solution is way nicer - not need for this pr anymore