pad_to_end()` (locf bake) crashes with an uninformative error when a selected column is all NA

[docxology]

Channel: public issue · Severity: medium

---

When a column selected by step_adjust_latency(method = "locf") is entirely NA within the data window — e.g. a location/signal that stopped reporting altogether — the locf path crashes with a cryptic error unrelated to the cause, instead of skipping or NA-ing the column cleanly.

What happens

R/utils-latency.R (HEAD 43b352f / main 7d8539b):

count_single_column <- function(col) {
  max(which(!is.na(col)))     # :236-238 — -Inf (with a warning) for all-NA
}

count_single_column is consumed in the slice() bound constructions at :219 and :227 inside pad_to_end(), which is called from the locf bake branch (R/step_adjust_latency.R:329-330). For an all-NA column, max(which(...)) is -Inf, and building the slice(min(...):n()) bounds fails with an error that doesn't mention the real problem. The sibling function get_latency() already handles the all-NA case gracefully (returns 0, R/utils-latency.R:130-134).

Repro (code-reading analysis; I don't have R available, so please confirm)

library(epipredict)
library(dplyr)

edf <- covid_case_death_rates |>
  filter(geo_value %in% c("ak", "ca"), time_value >= as.Date("2021-11-01")) |>
  mutate(case_rate_7d_av = NA_real_)   # signal stopped reporting entirely

r <- epi_recipe(edf) |>
  step_adjust_latency(c(case_rate_7d_av), method = "locf")

prep(r, edf) |> bake(edf)
# fails inside pad_to_end/slice with an uninformative bound error

Impact

A fully-NA predictor — a common situation when a signal is discontinued — crashes the locf path with a confusing error instead of degrading cleanly.

Suggested fix

Guard count_single_column() (return 0L/NA_integer_ on an empty which()), handle the sentinel in the slice() bounds, and skip all-NA columns with a warning naming them.