Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

read-cache-after-write consistency and event filtering for deletes

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

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

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
20/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
java, kubernetes
Domaine
backend, distributed-systems

Piste de recherche

Commencez par localiser les chemins du cache de lecture et du filtrage des événements pour les opérations de suppression dans Java Operator SDK, puis consultez l’issue parente pour connaître le comportement attendu. Comparez les ressources avec et sans finalizers ainsi que la remarque sur le verrouillage optimiste ; cette issue ne sera terminée qu’une fois la stratégie de filtrage des événements de suppression décidée et implémentée de manière cohérente.

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

Description

See also parent issue.

This might be a bit problematic, for resource without finalizer:

If the resource does not implement a finalizer, we could just record the UID of the resource and filter out events until we receive the delete event, that removes the cached resource ID.

The issue is with the resources with a finalizer, there we could define this like:

  1. Filter just the event that was caused by the delete operation (in this case, it just adds the deletion timestamp), and process subsequent events. By definition, only operations should happen afterwards, and that includes finalizer removals, but that is not enforced on the API level. Note that implementation-wise, this is an issue since the delete operation does not return the new resource nor it's version.

  2. We could filter out all the subsequent events until we receive a delete event. - But this might be too opionated, and especially if the controller would be restarted, users might see the resources again (although still marked for deletion). So probably not the right thing to do.

Notes:

  • optimistic locking does not seems to work for deletes either
Langage dominant
Java
Étoiles
943
Forks
245
Merge moyen
1 j 11 h
PR mergées (30 j)
28

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.