Repository navigation
_lock not found on metric #1140
Description
Hello! I hit an issue with a metric which has no labels invoking clear(). We fail on self._lock no existing. Turns out it was not created because there are no label values here, we actually have no lock on the instance later when we clear it. Why don't we always create this lock?
Activity
csmarchbanks commentedon Oct 7, 2025
Definitely a bug here, we shouldn't fail with such a unhelpful message.
That said, clearing (or removing as I believe this will also happen if you try to call remove on a metric with no labels) doesn't really make a lot of sense. Both clear and remove deal with labelsets which are also what are protected by the lock, so a metric with no labelset doesn't need the lock.
As far as this issue goes, what were you trying to accomplish calling clear on this metric? I can imagine providing a more helpful error message (maybe pointing users to
resetfor counters, or set(0) for gauges?), or just having clear/remove doing nothing when called on metrics without a labelset.zack-littke-smith-ai commentedon Oct 7, 2025
I have a pretty specific usecase to motivate use of https://github.com/zapier/prom-aggregation-gateway (not very vanilla Prometheus), but I have actually found a different approach that works for me. My initial implementation was to clear metrics immediately after sending them to this gateway, so that I would never double count. It is slightly more compute but it is actually more threadsafe and api-supported to calculate deltas from the last payload and send those, rather than resetting to 0.
My usecase for using the library in the first place is that I want to collect metrics in many short-lived jobs which cant be easily / reliably scraped.
fix: raise ValueError when clear() called on metric without labels (p…
csmarchbanks commentedon Jul 8, 2026
Fixed in #1184