Transient test failure in `test_allele_frequencies_with_str_cohorts_and_sample_query`

[jonbrenas]

I guess it could happen for other functions as well in test_snp_frq.py, I have not checked. There probably should be a test before the error is raised for the emptiness of a DataFrame (as I assume that it is the problem here):

FAILED tests/anoph/test_snp_frq.py::test_allele_frequencies_with_str_cohorts_and_sample_query[af1_sim] - ValueError: No amino acid change SNPs found for the given transcript and site mask.

[adilraza99]

Hi @jonbrenas,

I was able to reproduce the transient failure locally. It happens when the random parameter combination results in no variant SNPs or no amino-acid–changing SNPs, which causes the expected ValueError.

I’ve opened a PR that adds guards in the affected tests so that these legitimate empty-result cases are handled consistently with the existing patterns in the test suite.

Happy to adjust if you’d prefer a different approach.

[khushthecoder]

Hi @jonbrenas

Why this matters:

The current behavior of aa_allele_frequencies() treats "no amino acid change SNPs" as an exceptional error by raising ValueError. However, this is a perfectly legitimate outcome when working with restrictive filters (specific transcripts + site masks + sample queries). In practice, this means:

• For contributors: The flaky CI test erodes confidence in the test suite. Every red build requires manual investigation to determine if it's a real failure or just bad random luck, which slows down development.

• For users: Anyone building automated analysis pipelines (e.g., iterating over all transcripts in a genome) will encounter unexpected crashes. They'd have to wrap every aa_allele_frequencies() call in a try/except, which is poor API ergonomics.

• For the project: This inconsistency (some frequency methods handle emptiness gracefully, aa_allele_frequencies does not) creates a leaky abstraction that makes the library harder to use correctly.

My approach:

I followed the suggestion in the issue — check for emptiness before the error is raised — but went a step further: instead of just suppressing the error, I return a well-formed empty DataFrame with the correct schema and a UserWarning. This way:

1. Users can check len(df) == 0 naturally, just like with any other pandas operation
2. The warning provides feedback without halting execution
3. Downstream plotting code can handle the empty case gracefully
4. The fix is backwards-compatible — non-empty results are completely unchanged

I've tested the fix against all three affected test functions across all simulated API fixtures. Happy to adjust anything based on your feedback!
I have opened a PR for this issue. Could you please review it?#1147