v1 household copies to v2 fail when the household leaves out group collections
Les mainteneurs répondent en général sous 2 jours
Personne n'a encore pris cette issue.
- #4165 par @anth-volk — fermée sans fusion
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 25/100
Piste de recherche
Start with translate_legacy_household and its normalization step, which rejects people records that do not list every country-supported collection, and with _failure_category, which reports those rejections as translation. Compare them with policyengine-core's SimulationBuilder.build_from_entities, specifically add_default_group_entity and the last step of add_group_entity, to see which default groups it creates. Done when the two affected US households translate with those groups added, the UK and extra-key households still fail as unsupported, and the two events can be copied with process-v1-household-mirror-event.yml.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Problem
From 2026-10-29 to 2026-11-02, four production v1 household creates in the Public API (three US, one UK) logged V1 household immediate copy completed with outcome error and failure_category translation. Their household_mirror_events records stay pending, so those households have no v2 copy.
Cause
translate_legacy_household requires every person to be listed in a group of every collection the country supports. policyengine-core, which the Public API's v1 calculations use, does not. When it builds a simulation from a v1 household (SimulationBuilder.build_from_entities):
- a group collection that is omitted, or null, gets one group that holds every person (
add_default_group_entity); - a person that a present collection's groups leave out gets a group of their own (the last step of
add_group_entity).
Two of the US households list people and households, and leave out some or all of families, tax_units, spm_units and marital_units. v1 calculates them, but the translation's normalization rejects them with people record memberships must identify every country-supported entity collection, which _failure_category reports as translation.
The other two households are not valid v1 households, and v1 cannot calculate them either:
- one US household has an extra top-level key that is not an entity collection;
- the UK household has no
peoplecollection, and a person record at the top level.
policyengine-core raises SituationParsingError for both. The translation rejects them as legacy household contains unsupported collections, which is correct, so this issue leaves them pending.
Fix
Make the translation create, for each collection, the groups that policyengine-core creates: one group of everyone for an omitted or null collection, and a group of their own for each person a present collection leaves out. These groups have stable IDs after the named groups, no source_name (the v1 household has no name for them) and no values.
After the fix deploys, copy the two affected events with process-v1-household-mirror-event.yml, one event at a time.
- Langage dominant
- Python
- Étoiles
- 18
- Forks
- 33
- Merge moyen
- 2 j 21 h
- PR mergées (30 j)
- 93
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de PolicyEngine/policyengine-api
-
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
PolicyEngine/policyengine-api#4037 ·
Les mainteneurs répondent en général sous 2 jours
-
Difficulté 1/5 1-3 heures Accessibilité débutants 88/100
PolicyEngine/policyengine-api#3911 ·
Les mainteneurs répondent en général sous 2 jours
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 82/100
PolicyEngine/policyengine-api#3910 ·
Les mainteneurs répondent en général sous 2 jours
-
Assign every v2 route and service file to a layer and enforce the doc-only v2 layer rulesPeut-être pris @anth-volk l’a pris il y a 1 jour. Ouverteenhancement
Difficulté 4/5 3-5 jours Accessibilité débutants 20/100
PolicyEngine/policyengine-api#4190 ·
Les mainteneurs répondent en général sous 2 jours
-
Check that every test function asserts somethingPeut-être pris @anth-volk l’a pris il y a 1 jour. Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 25/100
PolicyEngine/policyengine-api#4187 ·
Les mainteneurs répondent en général sous 2 jours
Toutes les issues de PolicyEngine/policyengine-api
Issues similaires
-
fuzz fuzz-unconfirmed
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
Les mainteneurs répondent en général sous 1 jour
-
ready-for-agent
Difficulté 2/5 1-3 heures Accessibilité débutants 86/100
neilsh/stunt-reel#220 ·
Les mainteneurs répondent en général sous 1 jour
-
[Issue]: use_fp4_cache is accepted but ignored; the launcher always writes FP8 recordsPeut-être pris @0z5a l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
area: cli priority: p3 size: S type: bug
Difficulté 2/5 1-3 heures Accessibilité débutants 83/100
finos/open-resource-broker#757 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
Les mainteneurs répondent en général sous 6 jours