Report each day's production telemetry error groups as GitHub issues
Maintainer antworten meist innerhalb von 3 Tagen
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 20/100
- Issue-Typ
- Feature
- Klarheit
- Klar beschrieben
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- github-actions, google-cloud, python
- Bereich
- backend-api-design, observability
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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
regressionlabel 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.
- Vorherrschende Sprache
- Python
- Sterne
- 18
- Forks
- 33
- Ø Merge
- 2 T. 15 Std.
- Gemergte PRs (30 T.)
- 35
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus PolicyEngine/policyengine-api
-
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 88/100
PolicyEngine/policyengine-api#3911 ·
Maintainer antworten meist innerhalb von 3 Tagen
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 82/100
PolicyEngine/policyengine-api#3910 ·
Maintainer antworten meist innerhalb von 3 Tagen
-
Let a saved reform or household point at a new v2 policy or household without changing its IDEvtl. vergeben @anth-volk hat das heute übernommen. Offen
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 68/100
PolicyEngine/policyengine-api#4004 ·
Maintainer antworten meist innerhalb von 3 Tagen
-
Releases do not check that each environment calls its own simulation serviceEvtl. vergeben @anth-volk hat das heute übernommen. Offen
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 46/100
PolicyEngine/policyengine-api#4002 ·
Maintainer antworten meist innerhalb von 3 Tagen
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 18/100
PolicyEngine/policyengine-api#4000 ·
Maintainer antworten meist innerhalb von 3 Tagen
Alle Issues in PolicyEngine/policyengine-api
Ähnliche Issues
-
Validate non-divisible effective batch sizes in the Unsloth LoRA backendEvtl. vergeben @debesh-biswas hat das heute übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
`rx.Model` event arguments emit `PydanticDeprecatedSince20` once per payload keyEvtl. vergeben Ein verknüpfter Pull Request ist offen oder bereits gemergt. Offen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
reflex-dev/reflex#7634 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 2 Tagen
-
documentation
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 82/100
topoteretes/cognee#6239 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
ranaroussi/yfinance#3009 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Test discovery aborts on GPU builds without cuStateVec: check_cuStateVec expects a failed result but set_config() now raises RuntimeErrorEvtl. vergeben @dmeliksetian hat das heute übernommen. Offenbug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
Qiskit/qiskit-aer#2495 ·
Maintainer antworten meist innerhalb von 1 Tag