Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#3,989 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 3 dias

@anth-volk já está trabalhando nisso.

Desde 20/10/2026.

  • #3990 de @anth-volk — aberto

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
20/100
Tipo de issue
Funcionalidade
Clareza
Claramente especificada
Status de atividade
Estagnada
Stack de tecnologia
github-actions, google-cloud, python
Domínio
backend-api-design, observability

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Python
Estrelas
18
Forks
33
Merge médio
2d 18h
PRs com merge (30d)
36

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de PolicyEngine/policyengine-api

Todas as issues de PolicyEngine/policyengine-api

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.