zhijunn commented on PR #67604: URL: https://github.com/apache/doris/pull/67604#issuecomment-6358991452
Your diagnosis matches what I see independently. Two additions, and one note on why I filed a separate issue. **Independent evidence.** Reproduced on 2.1.11-rc01 with `doris.request.query.timeout.s` = 1 s on a 500M-row single-bucket table: 22 runs gave 9 silent short reads (job SUCCESS, zero errors, 4 or 2 rows against a baseline of 5), 6 full reads, 7 unrelated connect failures — 60% of the successful runs were silent. In production, a 168M-row dimension-table read was truncated this way on 2026-10-16 and wrote 7,936 rows with a NULL join key, with the job and the export both reporting success. Two attempts on the same tablet one second apart show both shapes: the first was not blocked at cancellation time and failed loudly; the second was already in `blocking_get()` and returned OK + `eos = true`. **Two things this PR does not cover.** 1. `ResultQueueMgr::cancel()` — scan context closed or GC'd — shuts the queue down and erases the map entry without setting a status, so a fetch blocked there gets `blocking_get() == false`, which `fetch_result()` turns into `*eos = true` and `OK`. The re-check here sits in the sentinel branch, so this path stays silent. Re-checking `queue->status()` right after `blocking_get()` and treating `!success` as a failure covers both with two lines. 2. Version coverage. On 2.1.x the status *is* written (`PlanFragmentExecutor::cancel()`, failed `open()`), so your `result_queue_mgr.cpp` hunk alone fixes that branch. From 3.0 on, external scan runs on the pipeline engine (`TPipelineFragmentParams`) and `PipelineFragmentContext::cancel()` has no `update_queue_status()` at all, so the sink-side change is what makes it work there. `fetch_result()` is byte-identical on 2.1/3.0/4.0/master; a one-hunk backport plus a branch pick would cover released versions. **Why a separate issue.** There was no issue for this defect at all, so the PR has nothing to close and no place to attach a branch-pick request. I filed https://github.com/apache/doris/issues/69509 to track the defect itself, the shut-down path above, and the backport; it links back here and carries the logs, reproduction and per-partition counts. I am not submitting a competing patch — I have no machine to build BE and no practical C++ experience. The issue and this PR describe the same defect, but the PR does not cover all of it, which is why I filed the issue separately so that the maintainers can see it; I remain glad to contribute what I can. ## 中文 你们的诊断与我的独立结论一致。补充两点，并说明我为何另开了一个 issue。 **独立证据。** 在 2.1.11-rc01 上以 1 秒查询超时、单桶表约 5 亿行复现：22 轮中 9 轮静默短读（作业成功、零错误，读取 4 或 2 行，基线 5 行）、6 轮读全、7 轮为无关的连接失败——成功执行中 60% 为静默。生产上 2026-10-16 一张 1.68 亿行维表的读取被如此截断，7,936 行关联键被写成空值，作业与导出均显示成功。同一 tablet 上相隔一秒的两次尝试分别表现为响亮失败与静默成功。 **两点未覆盖。** 1. `ResultQueueMgr::cancel()`（上下文关闭或回收）关闭队列并删除映射项但不写状态，阻塞方拿到 `blocking_get() == false`，被翻译为 eos。本 PR 的复查位于哨兵分支内，该路径仍静默；在 `blocking_get()` 之后复查并处理 `!success` 即可用两行覆盖。 2. 版本覆盖。2.1.x 上状态确有写入，本 PR 的 `result_queue_mgr.cpp` 改动即可修好该分支；3.0 起外部扫描走流水线引擎且取消路径不通知队列，故 sink 侧改动是必需的。`fetch_result()` 在四个分支上一致，backport 只需一个 hunk，另需 branch pick。 **为何另开 issue。** 该缺陷原本没有任何 issue，本 PR 既无 issue 可关闭，也无处挂 branch pick 请求。我提交了 https://github.com/apache/doris/issues/69509 跟踪缺陷本身、上述关闭路径与 backport，其中回链本 PR，并附日志、复现与逐分区计数。我不另提补丁——因为没有编译 BE 的机器，也缺少 C++ 实践经验。由于本 PR 与我的 issue 同源但修复内容未完全覆盖，因此我还是单独提了一个 issue，希望 Doris 维护者可以注意到；如果有机会，我仍愿意提供力所能及的贡献。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
