-
Notifications
You must be signed in to change notification settings - Fork 24
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
fix: Add debounce to branch search #3414
Conversation
Bundle ReportChanges will decrease total bundle size by 27 bytes (-0.0%) ⬇️. This is within the configured threshold ✅ Detailed changes
|
Bundle ReportChanges will decrease total bundle size by 27 bytes (-0.0%) ⬇️. This is within the configured threshold ✅ Detailed changes
|
❌ 1 Tests Failed:
View the top 1 failed tests by shortest run time
To view individual test run time comparison to the main branch, go to the Test Analytics Dashboard |
❌ 1 Tests Failed:
View the top 1 failed tests by shortest run time
To view individual test run time comparison to the main branch, go to the Test Analytics Dashboard |
❌ 1 Tests Failed:
View the top 1 failed tests by shortest run time
To view individual test run time comparison to the main branch, go to the Test Analytics Dashboard |
Test Failures Detected: Due to failing tests, we cannot provide coverage reports at this time. ❌ Failed Test Results:Completed 4900 tests with View the full list of failed testssrc/pages/RepoPage/BundlesTab/BundleContent/BundleSelection/BranchSelector.test.tsx
|
✅ Deploy preview for gazebo ready!Previews expire after 1 month automatically.
|
Looks like there is a debounce already from BranchSelector > Select > SearchField (here) |
Add debounce to the branch search element to improve the current slow timing that takes ~10seconds+ to load.
The branch search bar runs below query in postgres sql which takes ~3 seconds to run (20+seconds in the worst case) - see Sentry board.
Without a debounce, we are sending these 3+second queries over and over as the user types into the search bar and waiting until the last of those queries return a value until displaying it. So separate from trying to optimize the query, this debounce should cut down the time significantly on the frontend.
Closes codecov/engineering-team#2537
Underlying query:
RE: optimizing the query on the backend - There is an index on branches.repoid and one on branches.repoid,branches.branch but the latter index doesn't get picked up with
LIKE
operator. TheLIKE
operator does a full scan on all rows returned by therepoid
filter, according to theEXPLAIN ANALYZE
. There are options as an alternative toLIKE
like going for prefix search only instead but that is a worse user experience. I think this frontend fix gets us pretty far for now until we need to go change our db solution for search