in reply to Re^4: Leap second coming up. Check your date handling code (Cloudflare DNS outage)
in thread Leap second coming up. Check your date handling code

Very interesting, and quite surprising that they experienced such a problem. Speaks to the immaturity of Go I suppose. 

We are sorry that our customers were affected by this bug and are insp
+ecting all our
code to ensure that there are no other leap second sensitive uses of t
+ime intervals.

[download]
... might have been nice to do that beforehand. Doesn't seem like it would have been too hard to spot: 
- if rttMax == 0 {
+ if rttMax <= 0 {
    rttMax = DefaultTimeout
}

[download]
... if only they were coding in Perl and could use $rtt_max ||= $default_timeout;, LOL


The way forward always starts with a minimal test.

Replies are listed 'Best First'.
Re^6: Leap second coming up. Check your date handling code (Cloudflare DNS outage)
by Corion (Patriarch) on Jan 02, 2017 at 17:21 UTC

    How would your approach of

    $rtt_max ||= $default_timeout;

    [download]

    have worked out if $rtt_max was -1 ?

    Also, before tieing the maturity of a language to problems with its programs, have you checked if and whether time is monotonic?

    Personally, I would assume that the same problematic constellation would happen with Perl, and mocking both the time and the round trip times from DNS queries in a realistic manner only makes sense if your code base is small and you already suspect a problem in that location IMO.

[reply]
[d/l]
[select]

In Section Meditations