Open benjaminsavage opened 4 days ago
I'm not sure what that unexpected behaviour might be. Yes, if you fail to specify maxValue
and it turns out that the maximum used in the aggregation service is lower, that might be a problem. I believe that the proofs for Prio will not be in the correct form if the maximum is incorrect, so the value will be invalid.
It's a question of what is most ergonomic for authors. It's possible that the default value of 1 is enough. That would be because, when the maximum value is non-zero, there is a strong likelihood that the value is lower. That would mean that there is no ergonomic value in not specifying the maximum.
If you fail to specify "maxValue" and you use a non-uniform value for "value" across many conversions, then the aggregation service will observe a bunch of records to be aggregated which do not share a common "maxValue". I'd been assuming the aggregation service would insist on a consistent value being used and reject reports which do not match.
A suggestion from @martinthomson. Potentially, we could allow
maxValue
to be an optional parameter, and if unset, set it tovalue
. There are tradeoffs here. It could potentially lead to unexpected behaviour.