Summary
Two code paths load the ACS variable codebook with a hardcoded year = 2022 rather than threading through the year(s) the user actually requested. When a user calls compile_acs_data(years = 2024, ...), variable lookups and the raw→clean name crosswalk are built from the 2022 ACS codebook, which can silently mismatch the data actually returned.
Affected code
1. R/table_registry.R:647-650 — collect_raw_variables() ignores its year arg
collect_raw_variables = function(resolved_tables, year = 2022) {
suppressWarnings({suppressMessages({
census_codebook = tidycensus::load_variables(year = 2022, dataset = "acs5") # hardcoded
})})
compile_acs_data() passes year = years[1] (see R/compile_acs_data.R:273), but the function parameter is never used — the hardcoded 2022 overrides it.
2. R/generate_codebook.R:55 — no year parameter at all
census_variables = tidycensus::load_variables(year = 2022, dataset = "acs5")
generate_codebook() has no year argument, so the raw→clean crosswalk used by format_variable() (for codebook ACS-code labels) is always built from 2022.
Impact
- Tables with variables added/renamed/discontinued between 2022 and the requested year will produce wrong or missing codebook labels.
select_variables_by_name() (used by select_variables-sourced registry tables) returns variables from the 2022 codebook, which may not exist — or have different meanings — in the requested year.
- Symptom is silent: no error, just variables missing from output or mapped to stale ACS codes in the codebook.
Proposed fix
- In
collect_raw_variables(): replace year = 2022 in the load_variables() call with year = year.
- In
generate_codebook(): add a year parameter and thread it from compile_acs_data() (e.g., year = years[1], or attach years to the data attribute and pull it there).
Priority
Deferred — tracking only. Worth bundling with any broader work that reviews year-sensitive behavior in the codebook/variable-resolution pipeline.
Summary
Two code paths load the ACS variable codebook with a hardcoded
year = 2022rather than threading through the year(s) the user actually requested. When a user callscompile_acs_data(years = 2024, ...), variable lookups and the raw→clean name crosswalk are built from the 2022 ACS codebook, which can silently mismatch the data actually returned.Affected code
1.
R/table_registry.R:647-650—collect_raw_variables()ignores itsyearargcompile_acs_data()passesyear = years[1](seeR/compile_acs_data.R:273), but the function parameter is never used — the hardcoded2022overrides it.2.
R/generate_codebook.R:55— noyearparameter at allgenerate_codebook()has noyearargument, so the raw→clean crosswalk used byformat_variable()(for codebook ACS-code labels) is always built from 2022.Impact
select_variables_by_name()(used byselect_variables-sourced registry tables) returns variables from the 2022 codebook, which may not exist — or have different meanings — in the requested year.Proposed fix
collect_raw_variables(): replaceyear = 2022in theload_variables()call withyear = year.generate_codebook(): add ayearparameter and thread it fromcompile_acs_data()(e.g.,year = years[1], or attachyearsto the data attribute and pull it there).Priority
Deferred — tracking only. Worth bundling with any broader work that reviews year-sensitive behavior in the codebook/variable-resolution pipeline.