Confirming on arrival let a messenger's server delete messages the client never decrypted

The first fix is two lines swapped: load the saved state, then open the socket ^[8]. That closes the window by making the key read a precondition of being connected. It also puts browser storage on the path to going online, so a slow read now delays the socket ^[22].

That bug is the only one of the four the author attributes to real I/O timing. In the tests the key load was effectively instant, and the gap between connected and ready to decrypt existed only on a real machine doing real I/O ^[7]. "if your test setup completes instantly and production does not, you are not testing the same system," the author wrote in a dev.to post ^[9].

The second bug is about which event the client acknowledges. The old handler called `show(m)` and then `confirm(m.id)`, so the confirm fired even when `show()` threw ^[11]. The server treats a confirm as permission to delete the held copy ^[10]. "Arrival is not delivery," the author wrote ^[13]. The new handler confirms only when `handled(m)` is true ^[11]. There is one deliberate exception: a message belonging to a conversation whose keys are gone is confirmed anyway, because asking for it again would not help ^[12]. Without that carve-out an unreadable message comes back on every reconnect.

The third fix is one line: `const othersPresent = room.size - 1 > 0`, read before the broadcast, with `hold(message)` running only when it is false ^[15]. Whether the server keeps a copy now depends on a socket being open at send time. The first bug was exactly the case where the socket was open and the message died ^[6]. Under the new code nothing is held for that message, so the confirm-if-handled path has nothing to replay ^[21].

By the author's account, a server holding copies of an entire conversation is a very different privacy claim from one holding a message for a few seconds ^[17]. He had integration tests running against a real Postgres ^[4], and found the accumulated copies by looking in the database himself ^[14].

Each of the other three bugs is an assertion the suite could have made. A live delivery should leave the held-message table empty. If the handler throws, the message should still be sitting on the server. Removing a chat should leave no keys behind. All three are checks on state after a sequence, and they run in the same Postgres integration harness that was already passing ^[4]. The author's conclusion is that the answer is not to write more tests, since he had plenty and they were all green while the feature did not work at all ^[19]. Three of those four bugs needed the existing tests to look at what was left over when the sequence finished ^[20].