【问题标题】:Cloud Functions for Firebase error handling用于 Firebase 错误处理的 Cloud Functions
【发布时间】:2018-01-22 04:55:27
【问题描述】:

我想知道当我已经链接承诺并且如果出现问题我需要更新实时数据库时编写 node.js 代码的正确方法是什么?

代码如下:

export const testErrorHandling = functions.database
      .ref('/workqueue/{pushId}/something').onWrite(event => {

  // Exit when the data is deleted.
  if (!event.data.exists()) {
    return;
  }

  //This is the retry count, give up if more than 5 times have been retried.
  const data = event.data.val()
  if (data.count >= 5) {
    return
  }

  return event.data.ref.root.child(data.fulluri).once('value').then(snapshot => {
    //Process all, if ok, delete the work queue entry
    return event.data.ref.remove()  
  }).catch(exception => {
    console.log('Error!: ' + exception)

    //Log error, increase retry count by one an write to that 
    //location to trigger a retry

    //Is the line below OK?
    //return event.data.ref.child('count').set(data.count + 1)
  })

})

我猜这在许多情况下是常见的要求,但找不到示例,因为所有示例似乎都只是写入 console.error 并完成。 (这在现实世界中是不够的。)

【问题讨论】:

  • 只有当您可以在代码中实际处理错误时,您才应该捕获它们。那么你认为会出现什么问题会触发捕获?你想怎么处理?
  • 顺便说一句:目前无法在 Cloud Functions 中强制重试,但可能会在未来的版本中添加。
  • 我们正在 AWS Lambda 上创建一个 PDF,将其写入 Cloud Storage,验证它是否正确写入并且可以打开,使用包含书面 PDF 作为附件的邮戳发送电子邮件并相应地更新数据.我们可能会为所有 https 调用等设置重试,但是工作量和测试量有点太多了。编写幂等代码要容易得多(无论如何实现重试,都必须如此),然后重试整个过程。因此,通常我们会看到服务出现故障、导致临时错误代码或最终导致对云存储的写入损坏
  • 但此代码仅捕获写入数据库失败并尝试通过另一次写入数据库来发出信号。这种写入失败的最可能原因是网络连接问题。在这种情况下,第二次写入成功的机会非常小。
  • 是的,这只是示例。在从 firebase 读取和使用链式 then 捕获之间大约有十次调用各种系统。如果有任何呼叫向南,我们需要重新排队并重试。如果 Firebase 不起作用,则链不会启动,也不会造成任何伤害。由于代码是幂等的,我们可以尝试任意多次。不重试的唯一原因是数据或我们的代码有问题,在这种情况下,在几次 cron 启动紧急运行后,它最终会出现在我们的人工工作队列中,这些紧急运行是为徘徊的条目计时的。

标签: node.js firebase google-cloud-functions


【解决方案1】:

[Firebase 的云函数开发人员] 你的想法很聪明。它可以工作很多次,但不会捕获较低级别的问题,例如数据库不可用或应用程序中的超时(尽管可以通过将重试排入队列的 Promise.race 来解决)。

我们正在努力为核心产品添加重试。既然你提出了这个问题,我很想征求一些客户的意见。作为开发人员,您在重试策略中需要/期望哪些功能?您认为什么是合理的默认设置?您希望如何覆盖这些默认设置?

【讨论】:

  • 我们实际上对应用程序脱机等没问题,因为我们计划进行一项检查 cron 作业,该作业会触及任何早于 x 的工作队列条目,从而导致重新触发数据库触发器,其中x 是估计的最坏情况执行时间的 25 倍。通过这种方式,我们将捕获任何“丢弃”的工作队列条目并最终保持一致,其中大部分项目都得到了非常快速的处理。
  • 至于愿望清单,这里是这样:我很想看到每个函数重试策略,如果重试次数超过限制(默认),它会逐渐退出并放弃 5. 退避算法可能是指数的,所以情侣首先应该做的很快,其余的相对缓慢,间隔更大。我不知道如果有未捕获的异常添加自动重试是否为时已晚,但应该有一种方法可以选择手动确认一切正常。这是一个也应该对 Pub/Sub 触发器实施的要求,因为目前它太不可靠了:/
  • 感谢您的出色工作! CF for Firebase 正在发展成为一个了不起的产品!
  • 哦,现在我正在写作,我也很想看到 https 函数的声明性安全性 ala 数据库/存储安全性(默认为所有打开的东西?)。那太棒了!
猜你喜欢
  • 2018-01-02
  • 2020-11-30
  • 2018-06-11
  • 1970-01-01
  • 2018-09-10
  • 2018-06-17
  • 1970-01-01
  • 2019-02-04
  • 2018-10-02
相关资源
最近更新 更多