Wir haben ein Projekt in der Entwicklung, in dem wir Azure DocumentDb als Datenspeicher verwenden. Es lief großartig, ich mag es wirklich, wie es funktioniert und wie es schnelle Entwicklung ermöglicht, aber in letzter Zeit haben unsere Integrationstests angefangen zu scheitern.
Unsere Integrationstests erstellen und zerlegen bei jedem Test eine Sammlung in einer Datenbank. Ich frage mich, ob dieser Prozess die Datenbank irgendwie "kaputt gemacht" hat.
Ich habe unser Projekt auf die nackten Knochen reduziert und es hier eingecheckt: Ссылка
Wenn ich die Tests durchführe, erhalte ich den folgenden Fehler:
%Vor% verursacht durch einen Fehler beim Aufruf von _client.ReadDocumentCollectionAsync innerhalb der AggregateRepository.cs . Ich verstehe das nicht. Die Ausnahme ist im Code übereinstimmend, der zuerst prüft, ob die Sammlung existiert (tut es), wenn sie es nicht tut, erstellt sie es. Natürlich wird das Erstellen fehlschlagen, da die Sammlung existiert !!
Der zweite Fehlertyp ist:
%Vor% Das ist ebenso verwirrend, die Sammlung existiert wieder, aber das Dokument nicht, wir erstellen es zum ersten Mal mit einer einzigartigen GUID. Der Code Fehler ist in dem Aufruf von _client.UpsertDocumentAsync erneut in der Klasse AggregateRepository.cs
Ich habe dies viele Male unter Verwendung des Codes in dem oben erwähnten Github-Repo reproduziert, aber unter Verwendung einer spezifischen Datenbank und Sammlung von documentDb. Wenn ich auf eine andere, brandneue DB umschalte, funktionieren der Code und die Tests wie erwartet!
Deshalb denke ich, dass es darauf ankommt, wie wir eine bestimmte Datenbank verwenden. Dieses Projekt ist jetzt ein paar Wochen alt und alle Tests liefen bis gestern gut, wo sie wirklich anfingen, sporadisch zu versagen. Manchmal wären beide grün, oder der eine oder andere oder beide würden versagen.
Eine Frage, die ich habe, ist, ist es ein Problem für documentDb, wenn wir eine bestimmte Sammlung wieder und wieder erstellen und löschen, möglicherweise mehrmals pro Minute? Oder gibt es bekannte Fehlerfälle, wenn Sie dies tun?
Ich könnte natürlich einfach unsere Test-DB ablegen, eine andere erstellen und unsere Köpfe vergraben, in der Hoffnung, dass es eine einmalige Sache ist. Aber könnte das in prod geschehen? Ich möchte dem wirklich auf den Grund gehen. Ist es möglich, den inneren Zustand dieses "Gebrochenen" zu sehen? DB in irgendeiner Weise?
Ich erhalte jetzt den Fehler, selbst wenn ich die clean-Funktion im Testklasse . Also ich denke nicht, es ist ein Problem mit async und warten und das Löschen der Sammlung vor dem Lesen / Schreiben ist abgeschlossen.
Beachten Sie auch, dass ich in meinem realen Projekt keine Schleife mache, wie Sie es in der Testklasse finden. Dies ist nur so einfach für mich (und Sie?), die Tests mehrmals auszuführen, bis sie fehlschlagen. (was es für eine neue DB, die Sie haben könnten, nicht!)
Tags und Links azure c# azure-cosmosdb