Error in VECTOR_ELT on R-devel

[martinju]

# Minimal reproducible example

On the current R-devel, the following code

library(data.table)
dt <- data.table(a=1:4,b=c(1,2,1,2))
dt[,yes:=.N,by=b, verbose = TRUE]

Throws the follows the following error

Detected that j uses these columns: <none>
Finding groups using forderv ... forderReuseSorting: opt not possible: is.data.table(DT)=0, sortGroups=0, all1(ascArg)=1
forder.c received 4 rows and 1 columns
forderReuseSorting: opt=0, took 0.000s
0.000s elapsed (0.000s cpu) 
Finding group sizes from the positions (can be avoided to save RAM) ... 0.000s elapsed (0.000s cpu) 
Getting back original order ... forderReuseSorting: opt not possible: is.data.table(DT)=0, sortGroups=1, all1(ascArg)=1
forder.c received a vector type 'integer' length 2
forderReuseSorting: opt=0, took 0.000s
0.000s elapsed (0.000s cpu) 
lapply optimization is on, j unchanged as '.N'
Making each group and running j (GForce FALSE) ... 
Error in `[.data.table`(dt, , `:=`(yes, .N), by = b, verbose = TRUE) : 
  attempt access index 2/2 in VECTOR_ELT

This should be perfectly valid data.table code, right?
I get the same error both on 1.17.8 and 1.17.99 versions of data.table. The code runs without error on R-release and older.

I did not find any links to this issue when searching. Are you the data.table developers aware of this issue and working on it? Or do you know whether this is a temporary thing on R-devel?
I am about submit my package to CRAN and I am unsure how to handle this. Any input, or guidance on this would be highly appreciated.

# Output of sessionInfo()

R Under development (unstable) (2025-12-18 r89199 ucrt)
Platform: x86_64-w64-mingw32/x64
Running under: Windows 11 x64 (build 26100)

Matrix products: default
  LAPACK version 3.12.1

locale:
[1] LC_COLLATE=English_United States.utf8  LC_CTYPE=English_United States.utf8    LC_MONETARY=English_United States.utf8 LC_NUMERIC=C                           LC_TIME=English_United States.utf8    

time zone: Europe/Oslo
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] data.table_1.17.99

loaded via a namespace (and not attached):
[1] compiler_4.6.0    magrittr_2.0.3    R6_2.6.1          cli_3.6.5         tools_4.6.0       rstudioapi_0.17.1 brio_1.1.5        testthat_3.2.3    rlang_1.1.6      

[MichaelChirico]

Please confirm #7485 fixes this for you

[martinju]

It fixes the issue!

I am sorry for not spotting that. I also installed the dev version data.table with install.packages("data.table", repos="https://rdatatable.gitlab.io/data.table"), which then apparently did not have that PR included.

Before closing, may I ask how you suggest I approach CRAN with this? There is now a fix, but only in the development version, which may take some time to arrive on CRAN, I guess? I assume this affects many packages. Many thanks in advance.

[MichaelChirico]

which then apparently did not have that PR included.

Yes, it's very fresh, binaries can take maybe a few hours to be ready after each commit to master as binaries are only produced if tests are passing.

Before closing, may I ask how you suggest I approach CRAN with this?

Could you offer more context? You shouldn't be seeing this error on CRAN today AFAIK, so CRAN needn't be involved.

Anyway, data.table will be releasing to CRAN imminently to resolve our own deadline.

[martinju]

Could you offer more context? You shouldn't be seeing this error on CRAN today AFAIK, so CRAN needn't be involved.

I am submitting a patch for my own package, probably tomorrow. The tests in need to run on R-devel will then obviously fail, and I need to explain this to the CRAN team upon submitting. I just wonder whether there was a standard way to tell CRAN this is not an issue with your development version (other than e.g. linking to the PR and letting them know I have run tests with your dev version without errors).

Anyway good to know that it should be on CRAN in a few days.

[MichaelChirico]

I think a note along with your submission will suffice. The CRAN team are aware of the data.table issue & our timeline.

[martinju]

Thank for your input, sorry for the trouble :-)