Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: implement flake processing using timeseries models #1140

Merged
merged 1 commit into from
Mar 25, 2025

Conversation

joseph-sentry
Copy link
Contributor

  • remove code related to old upload states
  • create implementation of flake processing that consumes data from timescale
  • process flakes uses impl_type

idea is that we'll start with impl_type both for a while which will persist flakes to the current db table and the new one, then at some point we will detect flaky tests in the finisher by checking the new flakes table

Copy link

sentry-autofix bot commented Mar 13, 2025

🚨 Sentry detected 1 potential issue in your recent changes 🚨

Did you find this useful? React with a 👍 or 👎

@joseph-sentry joseph-sentry requested a review from a team March 13, 2025 19:04
def handle_pass(curr_flakes: dict[bytes, Flake], test_id: bytes):
curr_flakes[test_id].recent_passes_count += 1
curr_flakes[test_id].count += 1
if curr_flakes[test_id].recent_passes_count == 30:
Copy link
Contributor

Choose a reason for hiding this comment

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

moving this magic constant to the top level would make sense. and an explanation of "after X passes in a row, the test is not marked as flaky anymore"

Comment on lines +223 to +224
{"test_id": "test1", "outcome": "pass"},
{"test_id": "test1", "outcome": "failure"},
Copy link
Contributor

Choose a reason for hiding this comment

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

testing with 2x pass would trigger the error I mentioned above, as you clear the test from the current flakes, and on the second iteration try to access that yet again.

@@ -78,8 +80,13 @@ def run_impl(
extra=dict(repoid=repo_id, commit=commit_id),
)

if impl_type == "new" or impl_type == "both":
process_flakes_for_repo(repo_id)
Copy link
Contributor

Choose a reason for hiding this comment

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

in case you use both, you are locking twice in a row. maybe if you move the locking logic out of the function, and the invocation into the lock here, that could be avoided.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i think this is necessary because they're locking different locks and reading from different keys

there's an edge case where a commit is leftover if we lock only once:

call Task 1 with commit A, old_key = [A], new key = [B]
Task 1: takes repo lock 
Task 1: completes new invocation, old key = [A], new key = []
call Task 2 with commit B, old key = [A, B], new key = [B]
Task 2: fails to take lock and just drops 
Task 1: completes old invocation, old key = [], new key = [B]

B is left over and has to wait for another invocation of process flakes to get processed

Copy link

codecov bot commented Mar 24, 2025

Codecov Report

Attention: Patch coverage is 96.20853% with 8 lines in your changes missing coverage. Please review.

Project coverage is 97.71%. Comparing base (c9ed88b) to head (76a8a8e).
Report is 4 commits behind head on main.

✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
services/test_analytics/ta_process_flakes.py 92.85% 5 Missing ⚠️
tasks/process_flakes.py 57.14% 3 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1140      +/-   ##
==========================================
- Coverage   97.72%   97.71%   -0.01%     
==========================================
  Files         449      451       +2     
  Lines       36866    37036     +170     
==========================================
+ Hits        36028    36191     +163     
- Misses        838      845       +7     
Flag Coverage Δ
integration 42.81% <41.23%> (-0.08%) ⬇️
unit 90.51% <96.20%> (+0.08%) ⬆️

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.

@codecov-notifications
Copy link

codecov-notifications bot commented Mar 24, 2025

Codecov Report

Attention: Patch coverage is 96.20853% with 8 lines in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
services/test_analytics/ta_process_flakes.py 92.85% 5 Missing ⚠️
tasks/process_flakes.py 57.14% 3 Missing ⚠️

📢 Thoughts on this report? Let us know!

@joseph-sentry joseph-sentry requested a review from Swatinem March 25, 2025 14:52
@joseph-sentry joseph-sentry added this pull request to the merge queue Mar 25, 2025
Merged via the queue into main with commit ef132cd Mar 25, 2025
21 of 29 checks passed
@joseph-sentry joseph-sentry deleted the joseph/flake-proc branch March 25, 2025 15:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants