260714 pikapods n8n bug issue

快速结论：该问题发生在自托管 n8n（PostgreSQL 数据库）运行中数据库连接意外中断后，内置的 ping / recovery 机制未能自动恢复，连接池长期停留在不可用状态，只能通过重启进程恢复。优先排查 n8n 版本是否低于 2.35.0，以及容器内 readiness 探针是否长期返回 503 而 liveness 仍为 200。

适用环境：n8n 2.29.10，Docker 自托管（PikaPods 托管），Node.js 24.16.0，PostgreSQL，executionMode 为 regular，concurrency 为 8，单实例 cluster。操作系统信息在 Issue 中未给出。

最快修复方案：升级到 n8n 2.35.0 或更高版本。该问题已通过 PR #35752 修复并随 n8n@2.35.0 发布。

注意事项：该修复只确认关闭了本 Issue，不保证与 #17190、#14582、#10274 等旧版本报障完全同源；升级前建议先备份 PostgreSQL 数据库与 n8n 配置。若升级后仍出现 Connection terminated unexpectedly 且 readiness 持续 503，需要按新问题重新反馈。

问题场景

用户在 PikaPods 上自托管 n8n 2.29.10，后端使用 PostgreSQL。在负载平稳、无部署和配置变更的情况下，n8n 在持久化一次工作流执行结果时遇到数据库连接中断。此后 /healthz/readiness 持续返回 503 Database is not ready!，而 /healthz（liveness）一直返回 200，容器看起来始终处于 Running 状态，没有触发告警。约 69 小时后手动重启 pod，2 分钟内恢复。用户期望内置的 DB_PING_INTERVAL_SECONDS、DB_PING_MAX_FAILURES_BEFORE_RECOVERY、DB_RECOVERY_BACKOFF_MIN_MS、DB_RECOVERY_BACKOFF_MAX_MS 恢复机制能在数秒内检测并重连，但实际并未生效。

报错原文

errorMessage: "Connection terminated unexpectedly"
/healthz/readiness: 503 "Database is not ready!"
/healthz: 200

原因分析

根据 Issue 讨论，问题更可能是 n8n 的数据库连接池进入了一种自身无法识别为可恢复的状态，而不是基础设施层面故障。PikaPods 已确认同一时间共享 PostgreSQL 无事故，仅该 pod 的连接受影响，其他租户 pod 正常，说明是 n8n 内部的连接处理/恢复逻辑问题。

评论中提出的关键区分是：进程仍然存活（liveness 200），但数据库客户端“代际”（pool generation）再未回到可用状态。可能原因包括：ping 重试实际在运行但持续失败；恢复循环本身停止调度；恢复过程创建或复用的连接池/客户端被永久污染，而全新进程创建的连接池是健康的。既然完整重启进程约 2 分钟即可恢复，后两种情况值得优先怀疑。该问题已在 PR #35752 中修复并随 2.35.0 发布。

环境排查

确认 n8n 版本：Issue 中问题版本为 2.29.10，修复版本为 2.35.0。
确认 Node.js 版本：Issue 中为 24.16.0。
确认数据库类型与连接方式：PostgreSQL，自托管于 PikaPods。
检查容器健康检查配置：readiness 与 liveness 是否分离，readiness 是否会在数据库不可用时返回 503。
检查 n8n 事件日志中最后一次成功执行与 Connection terminated unexpectedly 的时间点。
确认执行模式（regular）、并发数（8）及单实例部署情况，排除多实例/集群相关因素。

解决步骤

记录当前 n8n 版本，确认是否低于 2.35.0。可在容器内查看版本或对照发布页面。
升级前备份 PostgreSQL 数据库及 n8n 配置与环境变量，尤其是与数据库连接、健康检查相关的配置。
将 n8n 升级到 2.35.0 或更高版本，该版本包含 PR #35752 的修复。
升级后重启 n8n 进程，确认服务正常启动且 /healthz/readiness 返回正常。
若暂时无法升级，可优先尝试在出现 readiness 持续 503 时重启 pod 作为临时恢复手段；这是 Issue 中确认有效的处置方式，但不是根因修复。
如仍可复现，按评论建议收集连接池代际相关信息（创建时间、最后成功查询时间、首次失败时间、连续 ping 失败次数、恢复尝试次数、连接池销毁/重建时间、最后错误类型），并反馈给 n8n 团队。

验证方法

升级到 2.35.0 或更高版本后，观察 n8n 在数据库连接中断场景下是否能自动恢复：/healthz/readiness 应在短暂失败后恢复为正常状态，而不是持续 503；/healthz 保持 200 的同时，readiness 不应长时间卡在失败状态。可结合事件日志确认不再出现长时间无日志且 readiness 持续 503 的情况。Issue 中原问题在手动重启后 2 分钟内恢复，可作为恢复速度的参考。