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
Currently Flagger assumes that a successful api call to prometheus (which contains a result), will be able to access v.Value[1], which will result in a panic if the user configured a metric that returns a range vector. I understand that instant vectors must be used but that does make Flagger vulnerable. I would think a better option would be to evaluate if values were returned from the result and send an error the same as NaN or no values found.
Add Values in the prometheusResponse struct so it will be unmarshaled for evaluation. While iterating the Result of the api response, if Values are present return an error message without triggering a panic. I don't see any drawbacks to this solution outside of an additional failure scenario.
Any alternatives you've considered? No
Is there another way to solve this problem that isn't as good a solution?
The other option would be to evaluate if v.Value[1] is nil, if so return an error instead of a panic. It think it all comes down to how elaborate you want the failure message to be back to the user.
The text was updated successfully, but these errors were encountered:
Describe the feature
Currently Flagger assumes that a successful api call to prometheus (which contains a result), will be able to access
v.Value[1]
, which will result in a panic if the user configured a metric that returns a range vector. I understand that instant vectors must be used but that does make Flagger vulnerable. I would think a better option would be to evaluate ifvalues
were returned from the result and send an error the same asNaN
orno values found
.Source: https://github.com/fluxcd/flagger/blob/main/pkg/metrics/providers/prometheus.go#L150
What problem are you trying to solve?
Better error handling
Proposed solution
Add
Values
in theprometheusResponse
struct so it will be unmarshaled for evaluation. While iterating theResult
of the api response, ifValues
are present return an error message without triggering a panic. I don't see any drawbacks to this solution outside of an additional failure scenario.Any alternatives you've considered? No
Is there another way to solve this problem that isn't as good a solution?
The other option would be to evaluate if
v.Value[1]
is nil, if so return an error instead of a panic. It think it all comes down to how elaborate you want the failure message to be back to the user.The text was updated successfully, but these errors were encountered: