Make failure handling in EventRecorder configurable (fail-on-error option)
維護者通常 1 天內回覆
已經有一個關聯 PR 被合併了。
- #3688 來自 @afalhambra-hivemq —— 已合併
評估
- 難度
- 3/5
- 預估耗時
- 1-2 天
- 新手友好度
- 68/100
- Issue 類型
- 功能
- 描述清晰度
- 描述清楚
- 活躍度
- 活躍
- 技術堆疊
- java, kubernetes
研究方向
Start by locating DefaultEventRecorder#record and the EventSink#emit call described in the issue. Read the recorder's existing tests and identify how its construction or configuration is covered. Add an opt-in fail-on-error setting while preserving the current default, then verify that enabled failures propagate and disabled failures remain logged and swallowed.
由索引模型根據 Issue 內容生成。
描述
Is your feature request related to a problem? Please describe.
Currently, DefaultEventRecorder#record treats recording strictly as "best effort": any exception thrown when writing to the API server via EventSink#emit is logged as a warning and swallowed:
try {
sink.emit(toEvent(context, event), context);
} catch (Exception e) {
// recording an event must never break the caller: a controller that fails to reconcile
// because it could not write an event is strictly worse than one that records nothing
log.warn("Could not record {} event ...", ...);
}
While swallowing errors is desirable for informational telemetry, in our use case (and in environments with strict audit, compliance, or state tracking requirements), emitting a Kubernetes Event is considered part of the required reconciliation side-effects. If the event cannot be persisted (e.g. due to RBAC issues, network partition, or API server failure), continuing reconciliation without failing leaves the cluster in an inconsistent or un-audited state. We want the reconciliation to fail and re-queue/retry when an event fails to be recorded.
Describe the solution you'd like
Make this behavior configurable. When enabled, failures to record an event should propagate as an exception to trigger standard error handling and reconciliation retries, while keeping the current non-failing behavior as the default.
Describe alternatives you've considered
Extending DefaultEventRecorder and overriding the record method. However, this is not clean because it requires duplicating framework logic (such as parameter validation and calling toEvent(...) / sink.emit(...)) just to bypass the try-catch block.
Additional context
None
- 主要語言
- Java
- 星號
- 945
- 分支
- 247
- 平均合併
- 2 天 10 小時
- 30 天內合併 PR
- 27
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
operator-framework/java-operator-sdk 的其他 Issue
-
Cannot record events outside reconciliation loop or for arbitrary resources (`RegisteredController#eventRecorder` missing)可能已有人在做 @afalhambra-hivemq 今天認領。 未關閉
難度 4/5 3-5 天 新手友好度 54/100
operator-framework/java-operator-sdk#3686 · 3 則留言 ·
維護者通常 1 天內回覆
-
on-demand
難度 4/5 3-5 天 新手友好度 42/100
operator-framework/java-operator-sdk#3671 · 1 則留言 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 62/100
operator-framework/java-operator-sdk#3643 · 7 則留言 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 45/100
operator-framework/java-operator-sdk#3568 · 1 則留言 · 1 個 reaction ·
維護者通常 1 天內回覆
-
難度 5/5 一週以上 新手友好度 25/100
operator-framework/java-operator-sdk#3563 ·
維護者通常 1 天內回覆
查看 operator-framework/java-operator-sdk 的全部 Issue
相似的 Issue
-
bug
難度 2/5 1-3 小時 新手友好度 78/100
hiero-ledger/hiero-mirror-node#14665 ·
維護者通常 1 天內回覆
-
kind/bug
難度 2/5 1-3 小時 新手友好度 65/100
cadence-workflow/cadence#8745 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 68/100
oracle/graalvm-reachability-metadata#12168 ·
維護者通常 1 天內回覆
-
area/frontend area/test kind/tech-debt
難度 2/5 1-3 小時 新手友好度 82/100
camunda/camunda#69073 · 1 則留言 ·
維護者通常 1 天內回覆
-
Patient profile returns a server error for a person with observation periods but no clinical records可能已有人在做 @DG47 今天認領。 未關閉
難度 2/5 1-3 小時 新手友好度 75/100
維護者通常 1 天內回覆