Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Fermée
  • Quelque chose ne va pas ?
#3,958 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 3 jours

Une pull request liée a déjà été fusionnée.

  • #3959 par @anth-volk — fusionnée

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
fastapi, postgresql, python, supabase
Domaine
api, backend, databases, documentation

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Python
Étoiles
18
Forks
33
Merge moyen
2 j 18 h
PR mergées (30 j)
36

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de PolicyEngine/policyengine-api

Toutes les issues de PolicyEngine/policyengine-api

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.