Ein Entwickler stieß auf einen merkwürdigen Bug, bei dem das Speichern neuer Einträge manchmal zu Fehlern aufgrund doppelter Primärschlüssel führte. Dieses Problem rührte von dem benutzerdefinierten Nachrichten-ID-Generator der Anwendung her, der den aktuellen Zeitstempel verwendete. Der Generator versuchte, schnelle Anfragen zu verarbeiten, indem er für eine Sekunde schlief, wenn Zeitstempel kollidierten. Dieser Ansatz war jedoch ineffizient und im Wesentlichen ein komplizierter Autoincrement-Zähler. Ein kritischer Fehler war, dass die previousId nie aktualisiert wurde, was bedeutete, dass Kollisionen nicht verhindert wurden. Das Problem wurde dadurch verschärft, dass die Anwendung auf mehrere Server verteilt war. Diese Verteilung bedeutete, dass selbst eine korrekt aktualisierte previousId ID-Kollisionen zwischen verschiedenen Knoten nicht verhindern würde. Mögliche Lösungen beinhalten die Einbeziehung maschinenspezifischer Kennungen wie MAC-Adressen oder die Verwendung großer Zufallszahlen. Alternativ schlägt der Entwickler vor, sich auf die native Auto-Increment-Funktionalität der Datenbank zu verlassen, anstatt auf benutzerdefinierten Code. Der aktuelle Durchsatz war niedrig genug, dass die Datenbank die ID-Generierung wahrscheinlich effektiv verwalten konnte.
previousIdnie aktualisiert wurde, was bedeutete, dass Kollisionen nicht verhindert wurden. Das Problem wurde dadurch verschärft, dass die Anwendung auf mehrere Server verteilt war. Diese Verteilung bedeutete, dass selbst eine korrekt aktualisiertepreviousIdID-Kollisionen zwischen verschiedenen Knoten nicht verhindern würde. Mögliche Lösungen beinhalten die Einbeziehung maschinenspezifischer Kennungen wie MAC-Adressen oder die Verwendung großer Zufallszahlen. Alternativ schlägt der Entwickler vor, sich auf die native Auto-Increment-Funktionalität der Datenbank zu verlassen, anstatt auf benutzerdefinierten Code. Der aktuelle Durchsatz war niedrig genug, dass die Datenbank die ID-Generierung wahrscheinlich effektiv verwalten konnte.