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

Ouverte
  • Quelque chose ne va pas ?
#3,687 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Une pull request liée a déjà été fusionnée.

  • #3688 par @afalhambra-hivemq — fusionnée

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
68/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
java, kubernetes
Domaine
backend, distributed-systems

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
Java
Étoiles
945
Forks
247
Merge moyen
2 j 10 h
PR mergées (30 j)
27

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de operator-framework/java-operator-sdk

Toutes les issues de operator-framework/java-operator-sdk

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.