Skip to content

Conversation

@ecordell
Copy link
Contributor

I wrote these tests because I suspected a bug here, but it looks like it was fine. The extra coverage doesn't hurt, though.

@ecordell ecordell requested a review from a team as a code owner June 25, 2025 18:26
@github-actions github-actions bot added the area/tooling Affects the dev or user toolchain (e.g. tests, ci, build tools) label Jun 25, 2025
Copy link
Contributor

@tstirrat15 tstirrat15 left a comment

Choose a reason for hiding this comment

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

LGTM

@ecordell ecordell enabled auto-merge June 25, 2025 18:27
@codecov
Copy link

codecov bot commented Jun 25, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.33%. Comparing base (28e248d) to head (5d9bce3).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2468      +/-   ##
==========================================
- Coverage   77.35%   77.33%   -0.01%     
==========================================
  Files         414      414              
  Lines       50712    50713       +1     
==========================================
- Hits        39224    39215       -9     
- Misses       9016     9022       +6     
- Partials     2472     2476       +4     

☔ 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.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

dsReady, err := hm.dsc.ReadyState(ctx)
if err != nil {
log.Ctx(ctx).Warn().Err(err).Msg("could not check if the datastore was ready")
return false
Copy link
Contributor

@miparnisari miparnisari Jun 25, 2025

Choose a reason for hiding this comment

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

This change makes sense to me, but why aren't we doing both checks in parallel? Say the datastore takes forever to respond, but the dispatcher already errored out, we will be waiting datastoreReadyTimeout when we could have returned "false" very quickly.

It also seems to me that (hm *healthManager) Checker can be simplified by using backoff.Timer.

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

Labels

area/tooling Affects the dev or user toolchain (e.g. tests, ci, build tools)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants