[BUG] fslice crash when ordering by variable with only missing values

[chihyunkim]

Describe the bug
Running fslice will yield an 'R encountered a fatal error' crash when grouping by a variable and a group has only missing values in the order.by variable.

Steps/Code to Reproduce

tibble::tibble(group_var = c("a", "a", "b", "b", "c", "c"),
                      order_var = c(1, 2, 3, NA, NA, NA)) |>
  collapse::fslice(group_var,
                   order.by = order_var,
                   how = "min", n = 1)

Expected behavior
In the repro example, group c should return only the first row in the group (or both rows if with.ties = TRUE)

Additional context
Run in R version 4.6.0 (2026-04-24) -- "Because it was There".

[SebKrantz]

@claude please investigate and suggest a minimal fix via PR.

[claude]

Claude finished @SebKrantz's task in 5m 0s —— View job • claude/issue-867-20260715-2238 • Create PR ➔

---

fslice crash fix

• Reproduce the crash (root-caused via code analysis)
• Find root cause in R/fslice.R or C/C++ code
• Implement minimal fix
• Add regression test / NEWS entry
• Push branch and provide PR link

Root cause: In fslice(..., how = "min"/"max", n = 1, with.ties = FALSE) with grouping, R/fslice.R calls .Call(C_gwhich_first, order.by, g, fmin.default(order.by, g, na.rm = na.rm, ...)) to locate, per group, the row whose order.by value equals that group's min/max. When a group's order.by is entirely NA (with the default na.rm = TRUE), fmin/fmax correctly return NA as that group's target. But gwhich_first() in src/small_helper.c (the REALSXP branch) compared values with plain ==, and under IEEE 754 NaN == NaN is FALSE — so no row is ever matched for that group, and its result index stays 0 (the "not found" sentinel). That invalid 0 index is then passed to ss(x, ind, check = FALSE), which skips bounds checking, causing an out-of-bounds C-level read and the fatal crash.

Notably, the sibling with.ties = TRUE code path (uses %==%, i.e. whichv() in src/programming.c) already special-cases ISNAN(px[i]) && ISNAN(pv[i]) for exactly this reason — gwhich_first() was just missing the equivalent check.

Fix: src/small_helper.c, gwhich_first(), REALSXP case — treat two NaN/NA values as a match, consistent with the existing whichv() convention:

for(int i = 0; i != l; ++i) if(pres[pg[i]] == 0 && (px[i] == pt[pg[i]] || (ISNAN(px[i]) && ISNAN(pt[pg[i]])))) pres[pg[i]] = i+1;

This makes an all-NA group correctly resolve to its first row (matching the issue's expected behavior). With with.ties = TRUE, all-NA rows in that group were already correctly returned since that path was unaffected by the bug.

Added a regression test in tests/testthat/test-fslice.R covering the exact repro (how = "min", how = "max", and with.ties = TRUE), plus a NEWS.md entry.

Note on verification: This sandboxed environment has no R installation, and installing one (via apt/docker pull) requires approval unavailable in this automated context, so I could not compile the package and run the test suite directly. I traced the fix carefully against the C source (confirming it mirrors the identical NaN-matching idiom already used in whichv()) and manually verified the expected test outputs row-by-row. Please have CI or a maintainer run devtools::test() / R CMD check to confirm before merging.