Follow-up from the instrumented US budgetary-impact run and PR discussion: #264 (comment)
economic_impact_analysis currently builds US program statistics from a hard-coded list of program variable names. The run completed the expensive baseline and reform simulations and produced quick aggregate outputs, but then failed in ProgramStatistics -> Aggregate.run() with StopIteration while looking up a configured variable in simulation.tax_benefit_model_version.variables.
Likely immediate mismatch: the US program list includes payroll_tax, but the US model/output path appears to expose/materialize employee_payroll_tax instead. Other entries may also be fragile, for example medicare may not correspond to a plain aggregate variable in the US package.
This pattern is especially fragile for the US package because variable names and output variables can change quickly. The analysis layer should probably either:
- validate the configured program list up front and raise a clear error listing missing variables,
- derive supported program statistics from model metadata/output metadata, or
- maintain an explicit country-versioned mapping that is tested against current US outputs.
The important distinction from the run: the final exception is an analysis-layer lookup bug, while the earlier VSCode crash was more consistent with resource pressure during the simulation phase.
Follow-up from the instrumented US budgetary-impact run and PR discussion: #264 (comment)
economic_impact_analysiscurrently builds US program statistics from a hard-coded list of program variable names. The run completed the expensive baseline and reform simulations and produced quick aggregate outputs, but then failed inProgramStatistics -> Aggregate.run()withStopIterationwhile looking up a configured variable insimulation.tax_benefit_model_version.variables.Likely immediate mismatch: the US program list includes
payroll_tax, but the US model/output path appears to expose/materializeemployee_payroll_taxinstead. Other entries may also be fragile, for examplemedicaremay not correspond to a plain aggregate variable in the US package.This pattern is especially fragile for the US package because variable names and output variables can change quickly. The analysis layer should probably either:
The important distinction from the run: the final exception is an analysis-layer lookup bug, while the earlier VSCode crash was more consistent with resource pressure during the simulation phase.