on the server side, it looks like the problem could have been avoided with better types - it seem that there was a confusion between status values that can include 0 and those that cannot (alternatively, perhaps better, there was no status for the case where the status was undefined?) and then a hand-written assertion that a particular case could not happen (and so was not tested for).
the bug report describes all that, roughly (if i've understood) but doesn't seem to be worried about the higher level issues - the inconsistent types and need for fragile human assertions about type logic.
(not java bashing - don't see why this couldn't be solved in java)
but i guess this is just a bug report. for an outage like this i suppose there's going to be a major review? is that all internal? would be interesting to watch.
oh, sorry - didn't look at code, assumed java from some comment. but either way, same point - when you talk about solving problems with types, people tend to assume you're thinking of haskell or similar, but just because you're not using some super-cool functional language doesn't mean you shouldn't demand all you can get from your type system.
(ps i was talking about the code on the server side; not chromium)
> (ps i was talking about the code on the server side; not chromium)
Oh I see.
> on the server side, it looks like the problem could have been avoided with better types - it seem that there was a confusion between status values that can include 0 and those that cannot (alternatively, perhaps better, there was no status for the case where the status was undefined?)
From what I understood, they are talking about protocol buffer types. The sync server sent message to chromium to throttle for all types say A, B, and C. Chromium didn't know about type C, some code returned 0 for unspecified type, another piece of code calculates index based on what is returned in the previous step, and then due to the 0, a negative index was accessed in the bitset leading to out of bound exception.
The issue is server sent all types to clients rather than sending only types known to the client, and the client didn't gracefully handle unknown types. I don't think a better type system would have helped the server - that looks like a logic bug, not a typing bug.
what i was trying to say is that you can (often) push this kind of logic bug into the type system - by having, if you like, different types of statuses, or a special type for unknown values (a "maybe status").
if you can do that then you can get the "infallible" compiler to provide the "this branch will not be executed" logic. but there may be efficiency trade-offs, or it may be so directly tied to low level protocols that it is impossible.
five ten years ago i would not have thought of the problem in this way - i would have agreed with you (and the bug report) that it is just logic. but slowly i am starting to learn to rely more on types. but i don't know enough here to suggest details...
the bug report describes all that, roughly (if i've understood) but doesn't seem to be worried about the higher level issues - the inconsistent types and need for fragile human assertions about type logic.
(not java bashing - don't see why this couldn't be solved in java)
but i guess this is just a bug report. for an outage like this i suppose there's going to be a major review? is that all internal? would be interesting to watch.