Created attachment 327755 [details] [review]
pad: Don't drop LATENCY queries with default implementation

If there is only one pad in the internal pads, when folding for
LATENCY queries it will just drop the response if it's not live.

This is maybe not the proper fix, but it will just accept the first
peer responses, and if there are any other pads, it will only take
them into account if the response is live.

This *should* properly handle the aggregation/folding behaviour of
multiple live peer responses, while at the same time handling the
simple one-pad-only-and-forward use-case

commit 794944f779f954375fc74a3fffcc2067bba6a3e5
Author: Edward Hervey <bilboed@bilboed.com>
Date:   Fri May 13 09:43:14 2016 +0200

    pad: Don't drop LATENCY queries with default implementation
    
    If there is only one pad in the internal pads, when folding for
    LATENCY queries it will just drop the response if it's not live.
    
    This is maybe not the proper fix, but it will just accept the first
    peer responses, and if there are any other pads, it will only take
    them into account if the response is live.
    
    This *should* properly handle the aggregation/folding behaviour of
    multiple live peer responses, while at the same time handling the
    simple one-pad-only-and-forward use-case
    
    https://bugzilla.gnome.org/show_bug.cgi?id=766360

Comment on attachment 327755 [details] [review]
pad: Don't drop LATENCY queries with default implementation

This was reverted again as it results in invalid values in various cases:
a) if the first pad is not live but a following pad is live
b) generally, non-live latency values make no sense and can't be used in a meaningful way. Any code using them is most likely buggy.

Please re-open if the original bug reappears and you have a testcase :)