长期承诺会导致NodeJS App无法通过就绪检查吗？

Question

我目前有一个异步功能，大约需要7分钟才能完成。它可以在localhost节点服务器上正常运行，但在大约6分钟后无法通过Google App Engine进行就绪检查，并导致应用重新启动（就绪检查为503状态）。

函数的结构如下：

await Promise.all(customers.map(customer => recursivelyDownloadProfiles(someRequestParams)));

const recursivelyDownloadProfiles = (request, profiles = []) =>
    downloadProfilesAndReturnNextPage(request).then(
        ([nextRequest, moreProfiles]) => {
            const allProfiles = [...profiles, ...moreProfiles];
            if (!nextRequest) {
                return allProfiles;
            }
            return recursivelyDownloadProfiles(nextRequest, allProfiles);
        }
    );

下载的每个页面都有5秒钟的“睡眠”超时时间，以保持在API配额之内。

我正试图了解这个问题-这是“非阻塞”代码吗？因此，即使我的递归是无限的（不是），为什么准备检查失败？

更新

查看准备情况检查日志，它们每次迭代发送200次，直到大约6分钟之后，然后它们在某个迭代中开始失败。 http请求阻止了准备情况检查吗？

Answer 1

我重新审视了此打开的错误，并找到了答案：这是实例上的内存不足错误。事实证明，配置文件的递归下载已达到1.25GB的RAM，并且实例每次都关闭。

在排除了带有日志记录的TIMEDOUT请求后，然后我进入了应用引擎控制台，发现了这个说明图：

当然，这不是我的个人计算机上的问题。

这是通过在本地计算机上记录以字节为单位的数组大小来确认的。

解决方案 从第三方API下载分页的结果时，这只是传播操作符的过度使用。 我没有使用const cumulativeProfiles = [...cumulativeProfiles, ...newlyDownloadedProfiles]，而是使用cumulativeProfiles.push(newlyDownloadedProfiles)，它占用了80多页，因此内存差异很大。