Skip to content

Fix #242: starter_rescued_runs metric always zero#243

Merged
whywaita merged 3 commits intomasterfrom
fix/242
Oct 3, 2025
Merged

Fix #242: starter_rescued_runs metric always zero#243
whywaita merged 3 commits intomasterfrom
fix/242

Conversation

@whywaita
Copy link
Copy Markdown
Owner

@whywaita whywaita commented Jul 3, 2025

fixes: #242

Summary

  • Renamed starter_recovered_runs metric to starter_rescued_runs to match naming convention
  • Fixed issue where the metric was always zero by adding increment logic when rescue jobs are enqueued
  • Changed internal variable name from CountRecovered to CountRescued for consistency

Test plan

  • Verified code compiles successfully
  • Checked that the metric is now incremented when rescue jobs are enqueued in enqueueRescueJob
  • Confirmed metric is exported with new name starter_rescued_runs

whywaita added 2 commits July 14, 2025 23:44
- Rename CountRecovered to CountRescued to match naming convention
- Rename starter_recovered_runs metric to starter_rescued_runs
- Add logic to increment counter when rescue jobs are enqueued
- Fix issue where metric was always zero
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR fixes a bug where the starter_rescued_runs metric was always reporting zero values and addresses naming inconsistencies in the codebase.

  • Renamed starter_recovered_runs metric to starter_rescued_runs for consistent naming convention
  • Added missing increment logic in enqueueRescueJob to properly track rescued jobs
  • Updated internal variable names from CountRecovered to CountRescued for consistency

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
pkg/starter/starter.go Renamed variable and added missing counter increment logic in rescue job handler
pkg/metric/scrape_memory.go Updated metric name and references to use consistent "rescued" terminology

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

Comment on lines +574 to +578
if count, ok := CountRescued.Load(target.Scope); ok {
CountRescued.Store(target.Scope, count.(int)+1)
} else {
CountRescued.Store(target.Scope, 1)
}
Copy link

Copilot AI Oct 1, 2025

Choose a reason for hiding this comment

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

This increment operation is not thread-safe. Multiple goroutines could read the same value and increment it simultaneously, leading to lost increments. Consider using atomic operations or a mutex to ensure thread safety.

Copilot uses AI. Check for mistakes.
Changed from non-thread-safe Load+Store pattern to atomic operations
using LoadOrStore with atomic.Int64 to prevent race conditions when
multiple goroutines increment the counter simultaneously.
@whywaita whywaita merged commit f18ad79 into master Oct 3, 2025
8 checks passed
@whywaita whywaita deleted the fix/242 branch October 3, 2025 06:36
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.

starter_recovered_runs must output zero

2 participants