Firebase Tools 中 DataConnect 的 @redact 与 @check 指令冲突问题解析

在 Firebase Tools 项目中，开发者在使用 DataConnect 服务时发现了一个关于权限控制指令 @redact 与安全检查指令 @check 交互时的异常行为。这个问题主要出现在处理嵌套数据结构时，当在子集合上使用 @redact 指令时，会意外影响父级结构中 @check 指令的正常工作。

问题背景

DataConnect 提供了两种重要的指令来控制数据访问：

1. @check - 用于在执行查询前验证访问权限
2. @redact - 用于在响应中隐藏特定字段

在典型的数据模型中，我们可能有组织(Organization)、组织成员(OrganizationMembership)和项目(Project)这样的关联实体。开发者希望在查询项目时，能够检查当前用户是否有权访问关联的组织数据。

问题重现

开发者设计了如下查询结构：

query GetProjectById($projectId: UUID!) @auth(level: USER) {
  project(id: $projectId)
    @check(expr: "this.organization.organizationMemberships_on_organization != []") {
    organization @redact {
      organizationMemberships_on_organization(where: { uid: { eq_expr: "auth.uid" } }) {
        uid
      }
    }
  }
}

按照官方文档说明，@redact 应该只影响最终返回的字段，而不影响 @check 表达式的执行。然而实际行为却是：当在 organization 或其子字段上使用 @redact 时，@check 表达式会报错，提示找不到相应的字段。

技术分析

这个问题本质上是一个作用域解析的bug。DataConnect 在处理 @check 表达式时，应该能够访问完整的对象结构，而不受后续 @redact 指令的影响。当前的实现中，@redact 指令过早地影响了整个查询路径的可用性。

从技术实现角度看，正确的处理流程应该是：

1. 首先解析完整的对象结构
2. 执行所有 @check 表达式验证
3. 最后应用 @redact 指令进行字段过滤

解决方案

Firebase Tools 团队已经确认这是一个bug，并计划在下一个版本中修复。修复的核心思路是确保 @check 表达式能够在不受 @redact 影响的环境中执行。

对于开发者来说，在修复发布前可以采取以下临时解决方案：

1. 将 @redact 移到最内层的字段上
2. 或者重构查询，将权限检查逻辑移到其他位置

最佳实践建议

在设计复杂的数据权限结构时，建议：

1. 将权限检查尽可能放在最外层
2. 避免在同一个查询中混合使用多层级的 @check 和 @redact
3. 对于复杂的权限逻辑，考虑使用视图(View)或自定义解析器

这个问题提醒我们，在使用新兴的数据层技术时，需要特别注意指令之间的交互行为，并进行充分的测试验证。