Make failure handling in EventRecorder configurable (fail-on-error option)

Aperta
  • Qualcosa non va?
#3,687 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #3688 di @afalhambra-hivemq — integrata

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
68/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java, kubernetes
Ambito
backend, distributed-systems

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Java
Stelle
945
Fork
247
Merge medio
2g 10h
PR unite (30g)
27

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di operator-framework/java-operator-sdk

Tutte le issue di operator-framework/java-operator-sdk

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.