Будет ли возвращаемый метод обновления из функции Firebase удовлетворять требованию обещания и автоматически регистрировать события?

#typescript #google-cloud-functions

#typescript #google-cloud-функции

Вопрос:

У меня есть облачная функция Firebase, которая выполняет запись в Firestore, когда пользователь выходит из клиента. Мне не нужно ничего возвращать клиенту, и я не хочу обрабатывать какие-либо ошибки (на данный момент), за исключением входа в консоль (что, я думаю, выполняется автоматически). Поэтому могу ли я отказаться then() от and catch() и просто вернуть вызов для обновления базы данных (следующим образом)?

 export const userDidSignOut = functions.https.onCall((data, context) => {
    const userId = data.userId
    const userSettingsUpdate = {
        "private.fcmToken": null
    }

    return admin.firestore().collection("userSettings").doc(userId).update(userSettingsUpdate)
})
  
  1. Удовлетворяет ли это требованию Firebase правильно обрабатывать все обещания?
  2. Будет ли это автоматически регистрировать успехи и сбои в журнале функций?
  3. В документации говорится, что я могу запросить асинхронные (не HTTPS) фоновые функции для повторной попытки при сбое, но меня смущает это утверждение. AFAIK вышеуказанная функция (которая вызывается из приложения iOS) является фоновой функцией (функцией, отличной от HTTP-запроса), но это https все еще функция. Подходит ли эта функция для автоматической повторной попытки?

Ответ №1:

update Метод Firestore возвращает обещание, которое разрешается при завершении записи на сервере. Поэтому, если вы вернете это из своей облачной функции, облачная функция будет завершена после завершения записи. Поскольку это единственный путь выхода в вашем коде, вы действительно возвращаете значение или обещание из каждого пути.

Успех и неудача этого обещания будут регистрироваться в журналах облачных функций.

onCall функции являются оболочками вокруг функций HTTPS и не являются фоновыми функциями. Они не могут быть автоматически повторены механизмом облачных функций. Если вы хотите, чтобы вызываемая функция была повторена по какой-либо причине, вам придется обрабатывать это в коде вашего клиентского приложения.

Комментарии:

1. Я думал, что существует 2 типа функций, связанных с их завершением: HTTP-триггеры и фоновые триггеры. HTTP-триггеры должны завершаться отправкой ответа, а фоновые триггеры должны возвращать обещание. Если моя функция действительно является функцией, запускаемой HTTP, почему я не должен отправлять ответ вместо возврата обещания?

2. Потому onCall что функции возвращают значение вместо отправки ответа . По сути: ваш код Firebase помещает в HTTP-функцию, которая улавливает возвращаемое значение и затем отправляет ответ (немедленно или после выполнения обещания) от вашего имени. Клиентский firebase-functions SDK получает полученный ответ и распаковывает его для вас.

3. Отличное объяснение, спасибо. И последнее: эта функция может завершиться сбоем двумя способами, правильно? Он может либо завершиться сбоем как сама функция, либо может завершиться сбоем внутри функции (запись в базу данных может завершиться неудачей). Если он не работает как сама функция (возможно, сетевая связь), клиент, который ее вызвал (приложение iOS), получит эту ошибку. Но если запись внутри функции не удалась, передает ли моя функция (как она написана в настоящее время) эту ошибку клиенту? Будет ли это возвращенное обещание сообщать клиенту об успехе или неудаче?

4. Насколько я знаю, отклоненное обещание приведет к ошибке, аналогичной проблеме с проводом, но проверить это должно быть довольно просто return Promise.reject() .