Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

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

I maintainer di solito rispondono entro 3 giorni

@anth-volk ci sta già lavorando.

Dal 20/10/2026.

  • #3990 di @anth-volk — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
github-actions, google-cloud, python
Ambito
backend-api-design, observability

Direzione di ricerca

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.

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

Descrizione

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.

Lingua principale
Python
Stelle
18
Fork
33
Merge medio
2g 15h
PR unite (30g)
35

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

Tutte le issue di PolicyEngine/policyengine-api

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.