error in intervals.union_overlapping

Bug #1079885 reported by Charles G Waldman on 2012-11-16
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Graphite
Fix Committed
Undecided
Unassigned

Bug Description

The function "union_overlapping" in intervals.py only works if the list of intervals is passed in in sorted order.
However, the ceres backend keeps the slice info in reverse sorted order:
  ceres.py:251 slice_info.sort(reverse=True)

which causes errors accessing Ceres data - measure_of_added_coverage in storage.py returns erroneous results, because it operates on IntervalSets which are invalid.

the attached patch makes the code more robust: it will work regardless of whether the list of intervals is sorted in forward or reverse direction, it is also more readable since it uses the 'overlaps' and 'union' methods of class Interval, rather than comparing start and end times (which is order-dependent)

Charles G Waldman (cgw) wrote :
Michael Leinartas (mleinartas) wrote :

Thanks, this is a great catch. I've merged this in master: https://github.com/graphite-project/graphite-web/commit/df01d98f090c2cd0c28876f3a409c4f0f0e1a92f

One question - I'm curious, what branch are you running for carbon to work with Ceres?

Changed in graphite:
status: New → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers