Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Make dual-write log failed v2 copies instead of returning HTTP 503

Geschlossen
  • Stimmt etwas nicht?
#3,958 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 3 Tagen

Ein zugehöriger Pull Request wurde bereits gemerged.

  • #3959 von @anth-volk — gemerged

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
fastapi, postgresql, python, supabase
Bereich
api, backend, databases, documentation

Rechercherichtung

Start with mirror_policy_after_commit and the policy, saved-policy, and household mirroring services; trace how failures reach the API routes after the v1 commit. Check the Stage 10 and Stage 11 migration docs for their failure sections. Done means post-commit copy failures are logged and return the normal v1 response, invalid selectors still return HTTP 503, and the migration docs describe the behavior.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Problem

With DB_WRITE_POLICY or DB_WRITE_HOUSEHOLD set to dual_write, the Public API copies each committed v1 policy, saved policy and household into Supabase in the same request. If that copy fails, the route returns HTTP 503, even though the v1 write has already committed:

  • mirror_policy_after_commit raises on any failure, including a Supabase outage, a policy the v2 catalog cannot translate (PolicyCatalogValidationError, LegacyPolicyTranslationError) and a missing catalog version (MetadataCatalogVersionNotFoundError). A retry repeats a translation failure, so that reform can never be saved.
  • A failed household copy also returns 503, and a retried POST creates a second v1 household row.

Policy writes happen on every reform save and every report run, so turning dual-write on in production would let any copy failure block users.

Proposed change

Make dual-write fail open: when the copy fails after the v1 commit, log the failure and return the normal v1 response.

  • Keep the mirroring services' existing behavior: log the failure with its metric (v1_policy_mirror_operations, v1_user_policy_mirror_operations, v1_household_mirror_operations) and failure_category, and leave saved-policy and household events pending.
  • Log the cases the services never see (no snapshot, revision or event to copy, or an unexpected error outside the service) with the same metrics.
  • Keep HTTP 503 for invalid database selectors, which are rejected before anything is written.
  • Update the failure sections of the Stage 10 and Stage 11 migration docs.

This is needed before dual-write is turned on in production.

Vorherrschende Sprache
Python
Sterne
18
Forks
33
Ø Merge
2 T. 6 Std.
Gemergte PRs (30 T.)
32

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus PolicyEngine/policyengine-api

Alle Issues in PolicyEngine/policyengine-api

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.