guard against small inputs in nCountRnaStratification

[GWMcElfresh]

Hi @bbimber,

Small check here to ensure the input scRNASeq dataset, before pseudobulking, can be assessed for nCountRNAStratification.

I'm pretty sure these prime-seq errors are just the typical on-the-fly type conversions based on the object's dimensions that R does all the time.

25 Jun 2026 17:20:30,040 DEBUG: 	6/8 [AvgExpression]
25 Jun 2026 17:20:49,323 DEBUG: 	Error:
25 Jun 2026 17:20:49,492 DEBUG: 	! unable to find an inherited method for function 'KLdiv' for signature 'object = "numeric"'
25 Jun 2026 17:20:49,571 DEBUG: 	Backtrace:
25 Jun 2026 17:20:49,616 DEBUG: 	    ▆
25 Jun 2026 17:20:49,629 DEBUG: 	 1. └─global GenerateAveragedData(seuratObj, groupFields = groupFields, addMetadata = addMetadata)
25 Jun 2026 17:20:49,677 DEBUG: 	 2.   └─CellMembrane::PseudobulkSeurat(...)
25 Jun 2026 17:20:49,739 DEBUG: 	 3.     └─flexmix::KLdiv(cluster_nCount_RNA_matrix)
25 Jun 2026 17:20:49,774 DEBUG: 	 4.       └─methods (local) `<fn>`(`<list>`, `<stndrdGn>`, `<env>`)

The assumption baked in here is that if we can't assess clustering, we'll just assume it's 'normalRNACounts' - since by definition the input is probably small. We'll typically filter those datasets based on cell counts prior to modeling, so not a huge deal in my opinion.

Let me know if you'd like anything else here!

GW

[GWMcElfresh]

Regarding the test failures, the Seurat one is easy to fix by sanitizing the gene lists to ensure they're within the Seurat object.

The omnipathR one is more in their wheelhouse. I am pretty sure it starts here upon decoupler failing to hit the omnipath API via OmnipathR::collectri(...) and thus pulling a cached table:
https://github.com/saezlab/OmnipathR/blob/3e1139172d3036ffd772ebb945bc5e338ac63fde/R/static.R#L128-L135
that is eventually kicked to here:
https://github.com/saezlab/OmnipathR/blob/3e1139172d3036ffd772ebb945bc5e338ac63fde/R/evidences.R#L122-L148
and doesn't have the required evidences column (see: https://r.omnipathdb.org/reference/static_table.html#ref-examples)

I tested to see if we were just hitting a timeout, so I bumped options(omnipathr.http_timeout) to no avail (failing within 21 seconds actually).

I think the problem with pulling the live omnipathR table is actually inside of omnipathR's taxonomy db, since they seem to store missing values as 'n/a', so an internal join they want to do fails on type.

traceback here:

OmnipathR::collectri(organism = 9606L, genesymbols = TRUE, loops = FALSE)

Error in `map_int()`:
ℹ In index: 1.
Caused by error in `map_int()`:
ℹ In index: 1.
Caused by error in `full_join()`:
! Can't join `x$ncbi_tax_id` with `y$ncbi_tax_id` due to incompatible
  types.
ℹ `x$ncbi_tax_id` is a <integer>.
ℹ `y$ncbi_tax_id` is a <character>.

[bbimber]

@GWMcElfresh : thanks for following up. if your last change fixes the seurat-related issue, then let's merge this. deCoupler/OmnipathR is a discrete failure that will only hit that package. I am wondering if we should transition from R to python for that, since their python package seems to have more active development.