greptimedb/remote-dyn-filter-task-06-validation.md

Task 06 - 端到端验证与回归基线

任务目标

建立 remote dyn filter 的功能、一致性、可靠性和性能验证矩阵，证明该机制在带来 pruning 收益的同时，不会因异常路径破坏查询正确性。

主要落点

• tests/
• tests-integration/
• 分布式 query / datanode / region 相关测试目录
• 基准或 benchmark 脚本目录

前置依赖

• Task 01-05 完成最小可用实现。

实现范围

1. 功能测试:
   • distributed hash join，小 build side 对大 probe side 产生远端 pruning
   • 无法序列化表达式时自动降级且结果正确
   • 初始 remote read 与后续 dyn filter update 使用同一个 remote_query_id + filter_id 逻辑 identity，并稳定绑定到对应 subscriber scan 集合
2. 一致性测试:
   • update 乱序
   • 重复 epoch
   • complete marker 早到 / 晚到
   • 仅部分 region 收到 update
   • remote_query_id / filter_id 缺失或关联键不完整时安全降级，不串线到其他 query state
   • datanode 本地 is_used() 类 eager cleanup 与 frontend unregister / TTL 兜底不会互相打架或造成误删
3. 可靠性测试:
   • frontend 中途停止发送
   • datanode 重启或 scan 提前结束
   • query cancel 后状态释放
4. 性能验证:
   • 高频小 update 与低频批量 update 对比
   • 不同 IN cardinality 阈值收益曲线
5. 建立回归基线，为后续 Phase 2/3 演进提供对照数据。

推荐子步骤

1. 先补最小集成测试，证明“能工作且失败不影响结果”。
2. 再补乱序 / 幂等 / 清理类单测，把状态机语义锁住。
3. 最后增加 benchmark 或 profiling 脚本，比较不同更新策略的控制面开销。
4. 为日志和 metrics 增加断言，确保观测口径不会回归。

验收标准

• 至少一个 distributed join 集成测试证明远端 pruning 生效。
• 所有异常路径测试都证明查询结果仍然正确。
• 状态机相关测试覆盖乱序、重复、complete marker、超时回收。
• 有可重复运行的性能对照基线，能支撑是否继续推进 stream/batch 演进。

风险与注意点

• 只测 happy path 没有意义，remote dyn filter 的价值在于异常时也必须安全退化。
• 性能测试必须同时看收益和控制面成本，不能只看扫描量下降。
• Phase 2/3 若没有基线，后续优化很难判断是真提升还是只是在搬移开销。