Fly.io overflow bug report (17bit, signed)

[IDONTHATECODING]

This is a bug report (I’m posting this here because it is not quite servere):

Due to some reasons, my deployment got to take about 20 hours. I manually stopped the deployment at that point, and I saw this:

(it shows an overflow error, because it is impossible that the build took -60273 seconds.)

Normally, such a long deployment is not expected to happen, but I think it would be better to fix the problem “just in case,” because it might ultimately cause some sort of more servere bugs.

For reference, I found that the site is using a mere “17 bit signed integer (Int17)”. My mathematical calculation as follows showed that the fly.io internally uses 17 bit signed integer for time representation:

(-60273) + lower_bound ≈ time_taken - upper_bound. using the approximations “lower_bound ≈ upper_bound” and “time_taken ≈ 72000“, I got “lower_bound ≈ upper_bound ≈ 66137”. Because the upper bound should be a power of 2, the actual value for the upper bound is 65536. That means, the integer type used is 17 bit signed integer.

[halfer]

I should think there are many possible causes of this error. I don’t think it’s necessary that we users guess the cause, but it is very useful to surface them.

[roadmr]

Thanks for the diagnostic attempt! It’s actually more trivial than a 17-bit number (unheard of in any programming environment I’ve evern seen). We’re subtracting “time it was created” from “time it was last updated”, which should generally result in a positive number; except, what if created is actually somehow bigger than updated? (hint: the result will be negative, as you observed here).

We’ll have a look.