ok. the way you worded it, it sounded like the mistake was the publishing of the info, not that certain info was made available via the api. i was questioning why certain data would be available via the api, but it appears it was only available during error.
Yes, for two different meanings of "error". I wonder if this ambiguity is part of what was confusing, so let me disambiguate.
There was a programming error in some error-handling code. If that makes sense, you can skip the following.
The first kind of error was a bug in our code. The API code is never supposed to send info to Firebase that you couldn't get by scraping the public website. Unfortunately, we wrote a line of code that (in a totally non-obvious way, which is why it got past both testing and code review) broke this rule.
The buggy line of code happened to live inside an exception handler. That is, it was only ever executed when a runtime error occurred. That's the second type of error we're talking about. An example might be a network timeout. These are infrequent, so the buggy code only ran infrequently.
Had the bug been in the happy path, testing would have caught it right away. In this case, though, even testing the error path didn't catch it, because certain other (basically random) conditions had to happen in order for the buggy code to leak the data. That's why we didn't know about it until Ovidiu told us.
