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

Report each day's production telemetry error groups as GitHub issues

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

Les mainteneurs répondent en général sous 3 jours

@anth-volk y travaille déjà.

Depuis le 20/10/2026.

  • #3990 par @anth-volk — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
20/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
github-actions, google-cloud, python
Domaine
backend-api-design, observability

Piste de recherche

Start with the linked pull request #3990 and review its workflow and related implementation. The issue specifies the daily Cloud Logging query, grouping and thresholds, issue updates and regressions, and privacy limits; compare the implementation against those requirements and verify the workflow with its dry run or available checks. Done means qualifying production error groups create or update issues while staging data and sensitive log content are handled as described.

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

Description

Problem

The Public API and the simulation API write structured telemetry to the central Cloud Logging bucket policyengine-observability, but nothing reviews their errors systematically. The six alert policies have no notification channels. A dry run of this change against 2026-10-19 found 15 error groups in production and staging. The largest, one exception on /<country_id>/report, failed about 14% of that route's requests that day, and nobody was told.

Change

A scheduled GitHub Actions workflow reports each US Eastern calendar day's errors as GitHub issues in this repository:

  • At 00:45 US Eastern it reads the previous day's ERROR records, plus the seven days before for comparison, from the bucket's linked BigQuery dataset.
  • It chooses one record per failed request and service, groups failures by a keyed fingerprint, and measures each group in production and staging: occurrences, affected requests, error rate on the affected routes, hourly rates, and first and last seen.
  • It opens one issue per production group with at least 3 occurrences in at least 2 requests, at most 5 per run, and updates existing issues. An issue closed as completed reopens with a regression label when failures return. Staging counts appear in the issues but never open one.

This repository is public, so issues, logs and job summaries may contain only fingerprints, counts, code-defined names (service, exception class, route template) and a Logs Explorer link, never error messages, stack text or identifiers.

Out of scope

  • Cloud Run platform failures (timeouts, out-of-memory kills, crashes before the application logs) are not forwarded to the bucket, so they are not reported. This is documented as a known gap.
  • Opening pull requests automatically from these issues is a later change.

Merge timing

Merge on or after 2026-10-23, once #3984 has run in production for a full Eastern day. Before that, unhandled 500s from before #3984 have no exception record, and would open issues for groups that stop matching once it is deployed.

Langage dominant
Python
Étoiles
18
Forks
33
Merge moyen
2 j 15 h
PR mergées (30 j)
35

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 PolicyEngine/policyengine-api

Toutes les issues de PolicyEngine/policyengine-api

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.