Idle CU sweep cannot reclaim a computing unit whose execution is stuck in a non-terminal state
维护者通常 1 天内回复
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 38/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- kubernetes, scala
调研方向
Start with ComputingUnitHelpers.reconcileVanishedKubernetesUnits and the idle Kubernetes computing unit sweep, then trace how workflow_executions status and last_update_time are used. Compare the existing listing-triggered reconciliation with the proposed scheduled pod-state check. Done means a live pod with a stale non-terminal execution no longer keeps an idle computing unit unreclaimed.
由索引模型根据 Issue 内容生成。
描述
Feature Summary
Follow-up to #6046.
Problem
The idle Kubernetes computing unit sweep treats a computing unit as busy whenever any of its
workflow_executions rows carries a non-terminal status code (status NOT IN (3, 4, 5)). That
test has no time bound, so an execution row left stuck in a non-terminal state keeps its computing unit off the sweep indefinitely, even though the unit is doing no work.
But the problem is, nothing else reclaims it either: ComputingUnitHelpers.reconcileVanishedKubernetesUnits only
runs when someone calls a listing endpoint, and it only checks whether the pod is already gone,
not whether the execution row is stuck somewhere. A live pod with a stuck row is missed on both paths.
maptoStatusCode also maps UNKNOWN (and TERMINATED) to -1, which is not in {3,4,5}. A row whose final status is -1 pins its unit off the sweep permanently. Fixing that means changing the codes amber writes, not this sweep's predicate.
Proposed Solution or Design
- Ignore a non-terminal execution row whose
last_update_timeis older than its own timeout. - Check execution status codes against actual pod state on a schedule, rather than only on a
listing request.
Either is a larger change than #6046 should carry, hence this follow-up.
Affected Area
No response
- 主要语言
- Scala
- 星标
- 325
- 派生
- 196
- 平均合并
- 4 天 2 小时
- 30 天内合并 PR
- 153
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
apache/texera 的其他 Issue
-
Disabled tools can still be called by the agent可能已有人在做 @shaynhornik 于 2 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 79/100
apache/texera#9122 · 4 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
Failed tool calls are marked as succeeded (isError is always false)可能已有人在做 @oliarmak-web 于 1 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 80/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
bug 🐞 Untriaged user issue
难度 2/5 1-3 小时 新手友好度 78/100
valkey-io/valkey-glide#7443 ·
维护者通常 1 天内回复
-
OpenAPI: PowSolutions requires pk, w and d, but a V2 solution needs only n可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭A-api C-bug S-ready-for-human
难度 2/5 1-3 小时 新手友好度 75/100
ergoplatform/ergo#2851 ·
维护者通常 2 天内回复
-
? - Needs Triage audit_4.2.0 feature request test
难度 2/5 1-3 小时 新手友好度 87/100
NVIDIA/cudf-spark#16614 ·
维护者通常 1 天内回复
-
bug unit testing velox backend
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 2 天内回复