OpenFlagr项目FindFlags接口软删除数据泄露问题分析

在OpenFlagr项目1.1.17版本中，FindFlags接口出现了一个值得注意的行为变更：当preload参数设置为True时，接口响应中会包含已被软删除（soft-deleted）的segments和constraints数据。这个问题在1.1.16版本中并不存在，属于版本升级引入的回归问题。

问题本质

该问题的核心在于数据库查询作用域（scope）的意外传播。OpenFlagr使用GORM作为ORM框架，在1.1.17版本中，由于PR#564的修改，FindFlags接口使用了Unscoped()方法来查询数据。这个无作用域限制的查询条件似乎被意外传播到了关联数据的预加载（preload）查询中，导致预加载的关联数据也忽略了软删除标记。

值得注意的是，GetFlag接口由于不涉及Unscoped()的使用，所以不受此问题影响，这进一步佐证了问题与查询作用域传播有关的判断。

技术细节分析

在GORM框架中，软删除通常通过在模型结构中定义DeletedAt字段实现。当执行删除操作时，GORM不会真正删除记录，而是更新该字段的时间戳。正常情况下，所有查询都应该自动过滤掉DeletedAt不为空的记录，除非显式使用Unscoped()方法。

在1.1.17版本的修改中，开发人员可能没有意识到Unscoped()的连锁效应。当对主模型使用Unscoped()时，这个"无视软删除"的特性会通过GORM的预加载机制传播到关联模型查询中，这与大多数开发者的预期行为不符。

影响范围

这个问题主要影响以下场景：

1. 使用FindFlags接口并设置preload=True的调用方
2. 依赖接口响应进行后续业务处理的逻辑
3. 需要精确获取有效segments和constraints的场景

在实际应用中，这可能导致客户端错误地处理已被删除的数据，比如尝试更新已经不存在的约束条件。

解决方案

临时解决方案是回退到1.1.16版本，或者手动构建1.1.17版本并回退有问题的提交。长期解决方案需要修正查询逻辑，确保Unscoped()不会传播到关联查询中。

从架构设计角度看，这也提醒我们在处理软删除数据时需要：

1. 明确区分不同场景下的数据可见性需求
2. 谨慎使用Unscoped()等会改变默认查询行为的操作
3. 对关联查询的作用域传播保持警惕
4. 增加针对软删除数据的测试用例

经验总结

这个案例很好地展示了ORM框架中查询作用域管理的复杂性。在实际开发中，我们需要：

1. 充分理解ORM框架的行为特性，特别是关联查询时的作用域传播规则
2. 版本升级时，除了功能测试外，还需要关注数据可见性等边界条件
3. 对于软删除这种业务常见模式，应该建立统一的处理规范
4. 考虑在API层增加数据过滤逻辑，作为数据库查询之外的二次保障

通过这个问题的分析，我们可以更好地理解现代ORM框架中查询作用域的管理机制，以及在复杂查询场景下保持数据一致性的重要性。