-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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 a bug in the priorityqueue metrics #3066
Conversation
@@ -34,7 +33,6 @@ func newQueueMetrics[T comparable](mp workqueue.MetricsProvider, name string, cl | |||
workDuration: mp.NewWorkDurationMetric(name), | |||
unfinishedWorkSeconds: mp.NewUnfinishedWorkSecondsMetric(name), | |||
longestRunningProcessor: mp.NewLongestRunningProcessorSecondsMetric(name), | |||
added: sets.Set[T]{}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This secondary bookkeeping was added because originally the queue called metrics.Add
when the queues Add was called before I realized this is wrong, now that metrics.add
is only called when an item was newly-added or became ready, this isn't needed anymore
The priorityqueue needs to call `metrics.add` but only once an item was ready. When an item was initially added with `After`, so not ready, then without which makes it ready, we didn't do that, resulting in potentially negative values for the queue depth metric.
Thx! /lgtm |
LGTM label has been added. Git tree hash: 3ca83db8c337ed490b65c0ecbb213af7afacb840
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alvaroaleman, sbueringer The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
The priorityqueue needs to call
metrics.add
but only once an item was ready. When an item was initially added withAfter
, so not ready, then without which makes it ready, we didn't do that, resulting in potentially negative values for the queue depth metric.