Lambda作为泄漏状态机吗？

Question

我有一项涉及OAuth 1互动的微服务。我发现自己处于两种具有完全相同的起始状态的Lambda函数的运行具有非常不同的结果（其中状态被认为是传入的“事件”，环境变量和来自API网关的“stageParameters”）。

这是一个Cloudwatch日志，显示两个背靠背运行：

您可以看到，当起始状态相同时，执行路径会很快变化。在第二种情况下（故障情况），您会看到日志条目“Auth state changed：null”...这确实很奇怪，因为实际上这是之前记录的甚至是第一行代码执行“处理程序”。这是函数处理程序的开头：

export const handler = (event, context, cb) => {
  console.log('EVENT:\n', JSON.stringify(event, null, 2));

那么这个过早的日志记录条目来自哪里？好吧，我们必须假设它在以前的执行中遗留下来。让我演示......它实际上是在先前执行中设置的事件监听器。此功能与Firebase数据库交互，第一次连接时会设置以下内容：

auth.signInWithEmailAndPassword(username, password)
  .then((result) => {
    auth.onAuthStateChanged(this.watchAuthState);

watchAuthState函数只是：

watchAuthState(user) {
  console.log(`Auth state changed:\n`, JSON.stringify(user, null, 2));
}

这似乎意味着当我第二次运行数据库时，我已经使用Firebase数据库进行了“初始化”，但显然身份验证已失效。我的首要目标是回到预测状态模型并使其每次执行完全相同。

如果有一些偷偷摸摸的方法在资源有用的方式重用Lambda执行之间的缓存状态，那么我想这也很有趣，但只有在我们能够实现预测状态机时才能这样做。

Answer 1

关于日志顺序，请查看每行开头的每个时间戳之后的ID。我相信这是调用ID。在以橙色突出显示的两行中，它们来自函数的不同调用。 EVENT日志是从ID为754ee的ID调用中记录的第一行。 Auth state changed: null行是来自早期调用函数的日志条目，调用ID以c40d5结尾。

看起来你在调用结束时将auth state设置为null，但Firebase连接是全局的，所以第二个函数调用认为Firebase连接已经初始化，但是由于验证被清空，它会抛出错误进行。

  

我的首要目标是回到预测状态模型和   让它每次执行完全相同。

然后你需要知道Lambda container reuse，而不是使用任何全局变量。