|
|
38fa3f2127
|
fix: 隧道断线自愈 + 修复配置负缓存永久固化
远端 RST 会把隧道反复踢掉（09-20 实测当天断 5 次，每次存活 15~25 分钟）。原先的
实现把「一次网络抖动」放大成「整个开发栈不可用」，根因有两处，本次一并修掉。
1) scripts/start-remote.mjs —— 隧道断了却拉着应用陪葬
隧道进程 exit 时直接 stopChildren()，把后端和前端一起杀掉，于是每一次 RST 都
升级成一次「网站打不开」，还得靠外部守护清残留、整树重启才能恢复。
改为「退避重连隧道本身，后端/前端进程不受影响」——这正是 autossh 的语义
（autossh 只负责重启 ssh，从不牵连被它服务的应用）。建立失败走 1s→30s 指数
退避，建立成功即重置退避。
顺带补齐保活参数：TCPKeepAlive=yes、ConnectTimeout=10，探活间隔 30s → 15s，
以便更快发现已被对端 RST 的死连接。
2) backend/src/config/cloudDatabase.js —— 配置负缓存被永久固化
系统库读取失败时把「空候选」写进缓存，而入口判断是
`if (cachedCloudConfigCandidates)` —— [] 在 JS 里是 truthy，于是这次失败被
永久固化：之后永不重试，直接抛「业务数据库尚未配置」500，隧道恢复了也没用，
必须重启后端。
改为「带 TTL 的负缓存」（默认 30s，可用 CLOUD_DB_CONFIG_NEGATIVE_TTL_MS 调整）：
入口用 `!== null` 判断，失败态到期自动重新解析，使隧道恢复后无需人工干预。
缓存清理收敛到 invalidateCloudConfigCache() 单点，避免日后只清数组、忘了清
TTL 时间戳而退化回「永不过期」。同时让「测试连接」入口显式失效，保证用户改完
配置点测试能立即看到真实结果。
顺带把请求超时默认值 600000ms → 60000ms：10 分钟 × maxAttempts=2 最坏挂
20 分钟，用户体感就是「卡死」；冷查实测 16~42s，60s 仍有充足余量。
验证：
- 新增 backend/test/cloudDatabaseConfigCache.test.js，锁定负缓存三段语义
（TTL 内不重复解析 / 到期必须重试 / 上游恢复后自动复原且成功态不被 TTL 淘汰）；
test/remote-access.test.mjs 补隧道保活参数、退避曲线，以及「自愈循环不得调用
stopChildren」的防腐化断言。
- 两处均做对照组实验：去掉保护后测试如实报错（负缓存 → 报 TTL 到期未重试；
隧道 → 把 stopChildren 加回去即被用例抓住），证明用例真能拦住回归。
- 后端全量 340 项 / 339 通过，唯一失败为 resilientSecretStore 的 Windows 权限
断言（环境固有，与本次无关）；check-syntax 通过。
- 本地实测：kill 掉隧道进程后 1 秒内自动重建（PID 36268 → 15816），后端进程
PID 未变（29580）、/health 仍返回 200。
|
2026-09-22 19:32:40 +08:00 |
|
