Electric-SQL 数据库删除时飞行中请求崩溃问题分析

问题现象

在 Electric-SQL 项目中，当系统处理飞行中的请求（如实时请求）时，如果此时对应的数据库被删除，会导致请求返回 500 错误。错误信息表明系统尝试访问一个不存在的 ETS 表（Erlang Term Storage，Erlang 的内置内存数据库）。

技术背景

Electric-SQL 使用 Erlang/Elixir 开发，其中 ETS 表用于存储和管理数据库状态信息。当数据库被删除时，相关的 ETS 表也会被移除，但此时如果有未完成的请求仍在尝试访问这些表，就会导致错误。

问题根源

深入分析错误堆栈可以发现，问题发生在以下处理流程中：

1. 系统通过 Electric.LsnTracker.get_last_processed_lsn/1 函数尝试从 ETS 表获取最后处理的 LSN（Log Sequence Number）
2. 此时对应的 ETS 表 :"single_stack:lsn_tracker" 已被删除
3. 导致 :ets.lookup/2 调用失败，抛出 ArgumentError

解决方案思路

正确的处理流程应该是：

1. 当准备关闭一个堆栈时，首先取消所有飞行中的请求
2. 停止接受该堆栈的新请求
3. 最后才真正关闭堆栈

这种顺序可以确保不会出现请求处理过程中资源被意外释放的情况。

技术实现细节

在修复方案中，特别需要注意以下几点：

1. 长轮询超时处理：修复方案需要确保在长轮询超时后，请求被正确处理，且堆栈仍处于活动状态
2. 错误处理机制：当检测到堆栈不可用时，应返回适当的错误信息而非崩溃
3. 资源生命周期管理：完善堆栈关闭流程，确保资源释放的顺序正确

最佳实践建议

对于类似系统的开发，建议：

1. 实现完善的资源生命周期管理机制
2. 对关键操作添加状态检查
3. 设计优雅的关闭流程，确保正在处理的操作能够正常完成或妥善终止
4. 添加适当的日志记录，便于问题追踪

总结

这个问题展示了在分布式系统中处理资源生命周期和并发请求时的典型挑战。通过分析 Electric-SQL 的这个具体案例，我们可以学习到如何更好地设计系统以确保稳定性和可靠性，特别是在资源动态管理的场景下。