fix(stream): handle notify output for nested diff external window

[JinqingKuang]

Description

Keep the stream runner from crashing when external-window output row indexes are cleared before nested diff returns its final block.

Issue(s)

• Fix: https://project.feishu.cn/taosdata_td/defect/detail/6930096221

Checklist

Please check the items in the checklist if applicable.

• Is the user manual updated?
• Are the test cases passed and automated?
• Is there no significant decrease in test coverage?

[Copilot]

Pull request overview

Prevents stream runner crashes when handling notify output for external-window queries where the per-window row-index metadata is cleared before a nested diff returns its final output block.

Changes:

• Add an early-return condition in the projection/indefinite-function path to avoid consuming additional downstream blocks after producing a result block for external-window streams.
• Harden stream-runner external-window output handling to tolerate missing pStreamBlkWinIdx in a specific “final window” scenario.
• Add a regression test case (Basic17) to reproduce the nested diff + notify crash scenario.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
test/cases/18-StreamProcessing/05-Notify/test_notify.py	Adds Basic17 regression case to exercise external-window notify with nested diff.
source/libs/new-stream/src/streamRunner.c	Handles output blocks even when external-window row-index array is missing/cleared, avoiding runner crashes.
source/libs/executor/src/projectoperator.c	Breaks out as soon as a result block is produced for external-window streams to keep stream runtime state aligned with the returned block.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[gemini-code-assist]

Code Review

This pull request introduces early exit logic for external-window outputs in the project operator and refactors the stream runner to handle scenarios where external-window row indices are missing. Additionally, a new test case has been added to verify the fix and prevent future regressions. A review comment suggests refactoring duplicated logic in the stream runner to improve maintainability and readability.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[JinqingKuang]

代码审查报告

修复目标：嵌套 diff 外部窗口输出时，pStreamBlkWinIdx 被提前清空导致 stream runner 崩溃。
整体方向正确，核心逻辑可信。以下是经过验证的问题。

---

[中] 类型窄化：rowsBefore 应声明为 int64_t

位置：source/libs/executor/src/streamexternalwindowoperator.c，extWinIndefRowsDo

int32_t rowsBefore 接收 pResBlock->info.rows（类型 int64_t，见 tcommon.h:212），存在隐式截断。

修复后调用：

extWinAppendWinIdx(..., pResBlock->info.rows - rowsBefore);

pResBlock->info.rows - rowsBefore 产生 int64_t 结果，而 extWinAppendWinIdx 最后一个参数为 int32_t，再次截断。extWinAppendWinIdx 内部计算 *pRowIdx = pBlock->info.rows - rows，若 delta 溢出则窗口起始行偏移记录错误。

在正常 stream 场景下块行数不会超过 INT32_MAX，实际不会触发，但属于类型层面的错误。

建议：将声明改为 int64_t rowsBefore = 0;，并对 extWinAppendWinIdx 的调用处加显式转换。

---

[中] allProcessByRowCtxShareFuncId 的检查范围不匹配

位置：source/libs/executor/src/projectoperator.c，projectApplyFunctionsWithSelect

bool splitByExternalWindow = ... &&
    allProcessByRowCtxShareFuncId(processByRowFunctionCtx);  // ← 检查外层全量数组

processByRowFunctionCtx 是当前投影中所有 processByRow 函数 ctx 的全量数组（可能跨越多个 functionId）。但实际执行时是按 funcId 分组依次处理，每次进入 processByRowInExternalWindows 的 pGroupedCtxArray 已经是同类函数的子集。

问题：若一个外部窗口查询同时包含两种 processByRow 函数（如 diff(a) 和 lead(b, 1)），allProcessByRowCtxShareFuncId 对全量数组返回 false，导致 两组函数都退回旧路径（不做分窗口重置）。旧路径在此场景下与这次 crash 触发方式相同，理论上仍可能崩溃。

当前 PR 描述的复现场景为纯嵌套 diff，allProcessByRowCtxShareFuncId 返回 true，修复有效。但建议在注释中说明此限制，或将检查粒度下移至 pGroupedCtxArray 级别。

---

[低] 错误路径下 pStreamBlkWinIdx 处于半重建状态

位置：source/libs/executor/src/projectoperator.c，processByRowInExternalWindows

函数开始时先 taosArrayClear(pStreamInfo->pStreamBlkWinIdx)，再逐窗口重建。若循环中某次 resetProcessByRowCtx 或 processFuncByRow 失败并跳到 _exit，pStreamBlkWinIdx 此时已清空原有内容，仅含前 i 个窗口的新条目。_exit 段不会从 pInputWinIdx 恢复原数组。

TDengine 的错误处理约定为失败即放弃任务，上层拿到错误码后通常触发任务重建，因此不会产生静默错误。但若未来上层加入重试逻辑，半损坏的索引可能导致难以排查的问题。

建议：在 _exit 段当 code != TSDB_CODE_SUCCESS 时，从 pInputWinIdx 恢复 pStreamBlkWinIdx 的原始内容。

---

总体结论

#	问题	严重度	置信度	可发布
1	rowsBefore 类型窄化（int32_t → int64_t）	中	高	inline
2	allProcessByRowCtxShareFuncId 检查外层全量数组，混合函数类型场景未被修复	中	高	summary
3	错误路径下 pStreamBlkWinIdx 半重建状态未恢复	低	中	summary

核心修复逻辑（extWinIndefRowsDo 传实际输出行数而非输入行数、stRunnerTopTaskHandleExternalWinOutputBlock 的空索引安全处理）验证正确，测试用例 Basic17 覆盖了描述的崩溃路径。

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 7 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.