• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

prometheus / client_ruby / 532 / 5
100%
master: 100%

Build:
Build:
LAST BUILD BRANCH: fix_with_labels
DEFAULT BRANCH: master
Ran 28 Oct 2019 12:14PM UTC
Files 32
Run time 3s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

28 Oct 2019 12:09PM UTC coverage: 0.0%. Remained the same
jruby-9.1.9.0

push

travis-ci

dmagliola
Fix bug where different label orders lead to different results

In the DirectFileStore, in order to store the labels hash on disk, we
turn it into a "querystring". The way this is done, we'll end up with
different strings if the same hash is passed in with its keys in
different order.

Since this string is used to index into the file where we store the data,
this will lead to two different values being stored for the same hash.
This is fine in cases where the aggregation is :SUM, because they end up
getting summed when the Client is summarizing. But in :ALL aggregation,
for example, you will end up with one value or the other, randomly.

The test in this commit reproduces this problem.

This way of serializing the labels is a bit slower (see PR for details),
but it's not a huge impact in the big scheme of things, and it leads to
the correct result.

Signed-off-by: Daniel Magliola <danielmagliola@gocardless.com>

0 of 1501 relevant lines covered (0.0%)

0.0 hits per line

Source Files on job 532.5 (jruby-9.1.9.0)
  • Tree
  • List 0
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Build 513
  • Travis Job 532.5
  • c59713d0 on github
  • Prev Job for jruby-9.1.9.0 on fix_label_order_bug (#530.5)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc