Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#3,989 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

@anth-volk ya está trabajando en esto.

Desde el 20/10/2026.

  • #3990 de @anth-volk — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
github-actions, google-cloud, python
Área
backend-api-design, observability

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
18
Forks
33
Merge medio
2 d 15 h
PR fusionados (30 d)
35

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de PolicyEngine/policyengine-api

Todos los issues de PolicyEngine/policyengine-api

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.