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

Collect e-mails before being sent

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

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
python
Domaine
backend

Piste de recherche

L’issue n’identifie pas les fichiers, les tests ni les points d’entrée à inspecter. Commencez par localiser les chemins de planification des notifications et des vérifications de ressources, puis définissez l’intervalle de regroupement, le comportement en cas d’échec immédiat, la gestion de la récupération et les tests nécessaires pour montrer que les notifications sont regroupées sans perdre les changements d’état.

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

Description

enhancement

Currently, GHC sends an e-mail whenever a resource check fails, and also when the resource check is working again. This is the case when you've set GHC_NOTIFICATIONS_VERBOSITY to False. With this variable set to True, you'll probably get even more e-mails.

I was performing a test with a large number of resources (close to 1000) and with a short test interval (every 5 minutes). The server being tested had some trouble coping with this test, so this was more a load test than a monitoring test. As a result GHC started sending a lot of e-mails, until a limit imposed by my provider was hit. This was worsened by the fact that earlier today a lot of tests failed due to wrong credentials being sent (HTTP 401 errors).

Would it be a good idea to have an option with which GHC can batch status reports and send them only after an interval has passed? For example, every minute, or every 5 minutes. Of course this means that the delivery of mails notifying the administrator of failures has a delay, so sending this interval too high is not advisable. Perhaps the first mail could be sent immediately, and any other mails within this interval could be batched.

Regarding my test: foremost this was just a test, but it made me think about differentiating between the type of checks which should be done. Some checks which have been added are meant to check the availability, where as other checks are meant to do more in depth checks on the content. The former checks could be performed at a higher interval than the latter. Nonetheless, I'm seeking a solution where I won't be hit by the limit imposed by my provider.

Langage dominant
Python
Étoiles
92
Forks
77
Merge moyen
1 h 39 min
PR mergées (30 j)
3

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 geopython/GeoHealthCheck

Toutes les issues de geopython/GeoHealthCheck

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

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