You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a result of #4689, a bug was introduced where we missed some spots where decrementing the queue metric should have happened. Most of those were caught in #4691, but the queues for some chains are still overestimating the length by ~1.4%.
Should understand why that is still happening. If all op_queue.pop(...)s have an associated op_queue.push(op) or an op.decrement_metric_if_exists() call the metric would be accurate, so it must be that some popped operations go out of scope without either.
The way I measured the inaccuracy was by checking the grafana metric against the number of items returned by the list_operations relayer endpoint.
The text was updated successfully, but these errors were encountered:
Problem
As a result of #4689, a bug was introduced where we missed some spots where decrementing the queue metric should have happened. Most of those were caught in #4691, but the queues for some chains are still overestimating the length by ~1.4%.
Should understand why that is still happening. If all
op_queue.pop(...)
s have an associatedop_queue.push(op)
or anop.decrement_metric_if_exists()
call the metric would be accurate, so it must be that some popped operations go out of scope without either.The way I measured the inaccuracy was by checking the grafana metric against the number of items returned by the
list_operations
relayer endpoint.The text was updated successfully, but these errors were encountered: