12 ms·

> This bug was extraordinarily rare, and because we have no metrics/remote log collection, there was an initial period where we had to spend time adding logging

> This bug was extraordinarily rare, and because we have no metrics/remote log collection, there was an initial period where we had to spend time adding logging and collecting user-submitted logs to try to track it down. Without telemetry, can you actually back up the claim that this issue was extremely rare?

hnarn 5y ago
Some details on how this assumption was made would be nice, but I think it's pretty obvious that any developer involved in a project can make a reasonable assumption of how rare a bug is depending on the technical details on what is required for the bug to happen. For example, if we say for the sake of argument that a hypothetical bug requires you to have more than ten contacts of the exact same name and these also need to share the same country and area code, one can make the assumption this use case is very rare without knowing the exact number of users that this applies to, just based on common sense regarding how the application is normally used. edit: The linked github issue says: > The TL;DR is that if someone had conversation trimming on, it could create a rare situation where a database ID was re-used in a way that could result in this behavior. It was very difficult to track down, with earlier phases involving getting additional logging into builds. Once we had some more information, it did in fact become our top priority, a fix was made, and we got it out as quickly and as safely as possible. The fix itself should make it so that database issues like the one that caused this bug can't happen again.
- NullPrefix 5y ago
  >for the sake of argument that a hypothetical bug requires you to have more than ten contacts of the exact same name and these also need to share the same country and area code This is only rare if you have a small social circle. My circle has multiple first name-collisions of at least 5 participants, but my circle is not very big and the area code is also quite small. Some countries do not use area codes for mobile phone numbers, which are used for Signal, meaning country code is the only area limiting factor.
  - desine 5y ago
    >for the sake of argument
    - NullPrefix 5y ago
      Yes. And for the sake of the same argument I made a counter argument, stating that some initially believed to be rare circumstances are actually not that rare.
      - hnarn 5y ago
        "For the sake of argument" does not mean "I invite you to debate this", it means the exact opposite: "let's assume this is correct/we agree/etc. for a while and debate what comes after". So in this case you are doing the exact opposite of what the phrase "for the sake of argument" is requesting. https://idioms.thefreedictionary.com/for+the+sake+of+argument https://idioms.thefreedictionary.com/for+the+sake+of+argumen... > I know you want to go to Stanford, but just for the sake of argument, let's talk about what some of the other schools you got into have to offer. This does not mean "I invite you to make a counter-argument as to why no other schools than Stanford are worth going to".
        NullPrefix 5y ago
        OKay, M[rs] English-as-a-first-language.
        hnarn 5y ago
        English is my second language.
        qu4z-2 5y ago
        It sounds to me like NullPrefix accepted the hypothetical bug, for the sake of the argument, and then addressed the rarity assumptions made about that bug. "For the sake of argument" doesn't mean "No debating" it means "Let's assume some thing x is taken as a given and go from there."
- z3t4 5y ago
  > The fix itself should make it so that database issues like the one that caused this bug can't happen again. I've said that a few times, and been wrong about it. :D I don't know what they mean by "where a database ID was re-used", but I guess it had to do with caching, and cache invalidation is one of the hardest part in computer programming.
  - dane-pgp 5y ago
    > cache invalidation is one of the hardest part in computer programming. Yes, famously it is one of the two hardest parts of computer programming, the other being naming things, and off-by-one errors.
- WesolyKubeczek 5y ago
  > a hypothetical bug requires you to have more than ten contacts of the exact same name and these also need to share the same country and area code Sounds like the village a part of my family tree comes from.
- varispeed 5y ago
  Why would anyone think that re-use of ID was a good idea?
  - hnarn 5y ago
    I'm not defending the practice of re-using a database ID, but it's absolutely something that can happen (or change) as an oversight rather than an active choice from the developer.
  - doctor_eval 5y ago
    Perhaps that’s why it was a bug?
- Griffinsauce 5y ago
  > just based on common sense regarding how the application is normally used Just based on assumptions of how the application is used. "falsehoods programmers believe" comes to mind. The uniqueness of names in your example could be false in some (or many? No idea) cultures.
- deleted 5y ago
  [deleted]
- jakequade 5y ago
  > it's pretty obvious that any developer involved in a project can make a reasonable assumption of how rare a bug is ... is it? The fact that a bug exists means there's a logic gap. You can try and patch it with theory, but that's just adding assumption to a scenario created from broken assumptions. Also, the job of telemetry in incident reporting isn't to be vague - its to add precision.
  - lmeyerov 5y ago
    There's probably a ratio of bug-report-to-occurrences that they're used to for difference kinds of bugs. Ex: If user-visible security bugs have good report rates, say 100-1000 leaks per 1 report, and 10 reports, then 1K-10K incidents. This is harder in b2b, but in b2c, PM's should have a feel for it..
    - conradev 5y ago
      You’d be surprised how difficult it is to estimate the frequency that someone sees a bug. The only way to have a “feel for it” is to base it on… other data. Say there is a bug that happens in the photo taking flow – you’d need to know how often people take photos in Signal. You’d think you could spitball something for that, but it is actually really hard. But if you log how often photos are taken, then that is a great starting point. But further, lower level logic errors like this, especially ones involving race conditions, are even harder to pin down. That is why on iOS you can log “faults” which are non-fatal but very not-expected events: https://developer.apple.com/documentation/os/logger/3551617-fault https://developer.apple.com/documentation/os/logger/3551617-... They generate reports with stack traces that you can use to a) judge the prevalence of an issue and b) see where it originated
CoryAlexMartin 5y ago
If you know the reproduction steps and you can look at the code, you should be able to make an estimate of rarity.
saagarjha 5y ago
Even with telemetry, would you be able to back up the claim that that the issue was rare? All too often, people add telemetry to something in an attempt to try to find things like this, but they end up leaking things elsewhere and not accounting for them. Bad statistics are more dangerous than no statistics, and all that.
- gsich 5y ago
  If this is the first instance of this bug being reported, then yes it's rare.
  - johnisgood 5y ago
    The rarity of a bug is independent from reports of it.
    - barsonme 5y ago
      That also depends on the severity of the bug. :)
    - gsich 5y ago
      No, those are directly correlated.
      - desine 5y ago
        The reports of it are correlated to the rarity, except in instances where reports are not generated, such as apps that do not collect error telemetry.
        agucova 5y ago
        Users can make reports manually, and you would even expect them to do so at a high rate in bugs like this. This implies a high correlation between bug reports and rarity.
        gsich 5y ago
gsich 5y ago
Even with, what telemetry would allow you to determine how many pictures (and presumably content) you sent to whom?
- andrewguenther 5y ago
  You can fix the bug but emit a metric on the original code path to estimate the impact after the fix is made. It wouldn't tell you who sent what to who, but would give you a better idea of impact for an incident report or postmortem.
kaba0 5y ago
I read it as bugs of this severity are extremely rare. Which claim doesn’t require telemetry.

hnarn 5y ago

Some details on how this assumption was made would be nice, but I think it's pretty obvious that any developer involved in a project can make a reasonable assumption of how rare a bug is depending on the technical details on what is required for the bug to happen. For example, if we say for the sake of argument that a hypothetical bug requires you to have more than ten contacts of the exact same name and these also need to share the same country and area code, one can make the assumption this use case is very rare without knowing the exact number of users that this applies to, just based on common sense regarding how the application is normally used. edit: The linked github issue says: > The TL;DR is that if someone had conversation trimming on, it could create a rare situation where a database ID was re-used in a way that could result in this behavior. It was very difficult to track down, with earlier phases involving getting additional logging into builds. Once we had some more information, it did in fact become our top priority, a fix was made, and we got it out as quickly and as safely as possible. The fix itself should make it so that database issues like the one that caused this bug can't happen again.

NullPrefix 5y ago
>for the sake of argument that a hypothetical bug requires you to have more than ten contacts of the exact same name and these also need to share the same country and area code This is only rare if you have a small social circle. My circle has multiple first name-collisions of at least 5 participants, but my circle is not very big and the area code is also quite small. Some countries do not use area codes for mobile phone numbers, which are used for Signal, meaning country code is the only area limiting factor.
- desine 5y ago
  >for the sake of argument
  - NullPrefix 5y ago
    Yes. And for the sake of the same argument I made a counter argument, stating that some initially believed to be rare circumstances are actually not that rare.
    - hnarn 5y ago
      "For the sake of argument" does not mean "I invite you to debate this", it means the exact opposite: "let's assume this is correct/we agree/etc. for a while and debate what comes after". So in this case you are doing the exact opposite of what the phrase "for the sake of argument" is requesting. https://idioms.thefreedictionary.com/for+the+sake+of+argument https://idioms.thefreedictionary.com/for+the+sake+of+argumen... > I know you want to go to Stanford, but just for the sake of argument, let's talk about what some of the other schools you got into have to offer. This does not mean "I invite you to make a counter-argument as to why no other schools than Stanford are worth going to".
      - NullPrefix 5y ago
        OKay, M[rs] English-as-a-first-language.
        hnarn 5y ago
        English is my second language.
      - qu4z-2 5y ago
        It sounds to me like NullPrefix accepted the hypothetical bug, for the sake of the argument, and then addressed the rarity assumptions made about that bug. "For the sake of argument" doesn't mean "No debating" it means "Let's assume some thing x is taken as a given and go from there."
z3t4 5y ago
> The fix itself should make it so that database issues like the one that caused this bug can't happen again. I've said that a few times, and been wrong about it. :D I don't know what they mean by "where a database ID was re-used", but I guess it had to do with caching, and cache invalidation is one of the hardest part in computer programming.
- dane-pgp 5y ago
  > cache invalidation is one of the hardest part in computer programming. Yes, famously it is one of the two hardest parts of computer programming, the other being naming things, and off-by-one errors.
WesolyKubeczek 5y ago
> a hypothetical bug requires you to have more than ten contacts of the exact same name and these also need to share the same country and area code Sounds like the village a part of my family tree comes from.
varispeed 5y ago
Why would anyone think that re-use of ID was a good idea?
- hnarn 5y ago
  I'm not defending the practice of re-using a database ID, but it's absolutely something that can happen (or change) as an oversight rather than an active choice from the developer.
- doctor_eval 5y ago
  Perhaps that’s why it was a bug?
Griffinsauce 5y ago
> just based on common sense regarding how the application is normally used Just based on assumptions of how the application is used. "falsehoods programmers believe" comes to mind. The uniqueness of names in your example could be false in some (or many? No idea) cultures.
deleted 5y ago
[deleted]
jakequade 5y ago
> it's pretty obvious that any developer involved in a project can make a reasonable assumption of how rare a bug is ... is it? The fact that a bug exists means there's a logic gap. You can try and patch it with theory, but that's just adding assumption to a scenario created from broken assumptions. Also, the job of telemetry in incident reporting isn't to be vague - its to add precision.
- lmeyerov 5y ago
  There's probably a ratio of bug-report-to-occurrences that they're used to for difference kinds of bugs. Ex: If user-visible security bugs have good report rates, say 100-1000 leaks per 1 report, and 10 reports, then 1K-10K incidents. This is harder in b2b, but in b2c, PM's should have a feel for it..
  - conradev 5y ago
    You’d be surprised how difficult it is to estimate the frequency that someone sees a bug. The only way to have a “feel for it” is to base it on… other data. Say there is a bug that happens in the photo taking flow – you’d need to know how often people take photos in Signal. You’d think you could spitball something for that, but it is actually really hard. But if you log how often photos are taken, then that is a great starting point. But further, lower level logic errors like this, especially ones involving race conditions, are even harder to pin down. That is why on iOS you can log “faults” which are non-fatal but very not-expected events: https://developer.apple.com/documentation/os/logger/3551617-fault https://developer.apple.com/documentation/os/logger/3551617-... They generate reports with stack traces that you can use to a) judge the prevalence of an issue and b) see where it originated

CoryAlexMartin 5y ago

If you know the reproduction steps and you can look at the code, you should be able to make an estimate of rarity.

saagarjha 5y ago

Even with telemetry, would you be able to back up the claim that that the issue was rare? All too often, people add telemetry to something in an attempt to try to find things like this, but they end up leaking things elsewhere and not accounting for them. Bad statistics are more dangerous than no statistics, and all that.

gsich 5y ago
If this is the first instance of this bug being reported, then yes it's rare.
- johnisgood 5y ago
  The rarity of a bug is independent from reports of it.
  - barsonme 5y ago
    That also depends on the severity of the bug. :)
  - gsich 5y ago
    No, those are directly correlated.
    - desine 5y ago
      The reports of it are correlated to the rarity, except in instances where reports are not generated, such as apps that do not collect error telemetry.
      - agucova 5y ago
        Users can make reports manually, and you would even expect them to do so at a high rate in bugs like this. This implies a high correlation between bug reports and rarity.
      - gsich 5y ago

gsich 5y ago

Even with, what telemetry would allow you to determine how many pictures (and presumably content) you sent to whom?

andrewguenther 5y ago
You can fix the bug but emit a metric on the original code path to estimate the impact after the fix is made. It wouldn't tell you who sent what to who, but would give you a better idea of impact for an incident report or postmortem.

kaba0 5y ago

I read it as bugs of this severity are extremely rare. Which claim doesn’t require telemetry.