Лично я бы не классифицировал это как «весьма вероятную» ошибку. На практике единственное, что вас беспокоит из-за сбоя, - это создание документа, а для кода node.js это может произойти только в том случае, если вы превысите некоторое ограничение Firestore, которое «крайне маловероятно», если вы не обрабатываетеМНОЖЕСТВО новых пользователей, чьи UID попадают на один внутренний осколок Firestore, превышающий его внутренний порог (см. limit ). UID довольно случайны и должны распространяться очень широко, так что это не должно быть проблемой. Он может также потерпеть неудачу, если вашему серверу не хватает доступа к Интернету, но каковы на самом деле шансы его потери подключения, если он только что завершил создание пользователя?
Поскольку у вас есть только две операции здесь, кажется, что вы могли бы простопроверьте, не является ли документ set()
(и обязательно await
возвращенное обещание, которое сейчас отсутствует). И если это не удается, просто удалите пользователя и верните ошибку клиенту. И если вы беспокоитесь о том, что удаление пользователя также может завершиться неудачей, я думаю, что вы, возможно, чрезмерно спроектировали этот конкретный фрагмент кода. Позже вы всегда можете написать код, который периодически проверяет учетные записи пользователей, чтобы выяснить, нет ли у них соответствующих документов Firestore, и удаляет их.
Вы можете сделать это намного проще, также , используя облачные функции для автоматическогосоздать документ после создания учетной записи пользователя . И если вы пометите эту функцию как «повторная попытка», если создание документа завершится неудачно, он будет повторять попытку документа в течение нескольких дней, пока он не будет работать.