Skip to content

Conversation

perebaj
Copy link
Contributor

@perebaj perebaj commented Apr 22, 2025

Description

Handle conflicts in prw v2

Link to tracking issue

Partially fixes #33661

Copy link
Contributor

@jmichalek132 jmichalek132 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, Thank you for picking this up.,

Copy link
Member

@krajorama krajorama left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi, nice job. I have a comment on comments :) Also it would be nice to test the collision handling somehow, either find a conflict (I've started to run a simple finder on 4 cores, maybe get lucky) or make the signature function be possible to influence.

if len(ts1.LabelsRefs) != len(ts2.LabelsRefs) {
return false
}
// As the labels are sorted as name, value, name, value, ... we can compare the labels by index jumping 2 steps at a time
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

plz update the comment on (new) line 134:

// TODO: Read the PRW spec to see if labels need to be sorted. If it is, then we need to sort in export code. If not, we can sort in the test. (@dashpole have more context on this)

since we're going to depend on this, it should say something like "We need to sort labels for..."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I don't know if I got it. Here we are comparing the LabelsRefs from different TSs, that are a list of integer arranged to represent: name, value, name, value....

The sort that we are doing on L132-L135 is related to sort the []prompb.Label. The confusion here was made because I used the sort word?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the sort word is a bit ambiguous here, let's say

Suggested change
// As the labels are sorted as name, value, name, value, ... we can compare the labels by index jumping 2 steps at a time
// As the labels are ordered as name, value, name, value, ... we can compare the labels by index jumping 2 steps at a time

But anyway, isSameMetricV2 will only work correctly if the order of labels is consistent, since otherwise it will say "not the same" for {a="1", b="2"} vs {b="2", a="1"} label sets.

On lines 132-135 we're sorting the labels []prompb.Label , but then we're converting these labels into the references on lines 137-143. So the order of the references is the same as the order of the sorted labels. Which means that we ensure consistent order for isSameMetricV2 with the sort on 132-135.

I did take a look at where the labels come from and it's createAttributes which will return consistent ordering probably - config changes not withstanding. So we could probably get away without making the sort, but I feel like that's brittle.

}
ts := writev2.TimeSeries{

sig := timeSeriesSignature(lbls)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a future PR: timeSeriesSignature also does a sort by label name.

Copy link
Contributor Author