Attempt to fix #4852 by explicitly loading variants

[dnil]

This PR adds a functionality or fixes a bug.

Testing on cg-vm1 server (Clinical Genomics Stockholm)

**Prepare for testing** 1. Make sure the PR is pushed and available on [Docker Hub](https://hub.docker.com/repository/docker/clinicalgenomics/scout-server-stage) 1. Fist book your testing time using the Pax software available at [https://pax.scilifelab.se/](https://pax.scilifelab.se). The resource you are going to call dibs on is `scout-stage` and the server is `cg-vm1`. 1. `ssh @cg-vm1.scilifelab.se` 1. `sudo -iu hiseq.clinical` 1. `ssh localhost` 1. (optional) Find out which scout branch is currently deployed on cg-vm1: `podman ps` 1. Stop the service with current deployed branch: `systemctl --user stop scout.target` 1. Start the scout service with the branch to test: `systemctl --user start scout@` 1. Make sure the branch is deployed: `systemctl --user status scout.target` 1. After testing is done, repeat procedure at [https://pax.scilifelab.se/](https://pax.scilifelab.se), which will release the allocated resource (`scout-stage`) to be used for testing by other users.

Testing on hasta server (Clinical Genomics Stockholm)

**Prepare for testing** 1. `ssh @hasta.scilifelab.se` 1. Book your testing time using the Pax software. `us; paxa -u -s hasta -r scout-stage`. You can also use the WSGI Pax app available at [https://pax.scilifelab.se/](https://pax.scilifelab.se). 1. (optional) Find out which scout branch is currently deployed on cg-vm1: `conda activate S_scout; pip freeze | grep scout-browser` 1. Deploy the branch to test: `bash /home/proj/production/servers/resources/hasta.scilifelab.se/update-tool-stage.sh -e S_scout -t scout -b ` 1. Make sure the branch is deployed: `us; scout --version` 1. After testing is done, repeat the `paxa` procedure, which will release the allocated resource (`scout-stage`) to be used for testing by other users.

How to test:

1. how to test it, possibly with real cases/data

Expected outcome: The functionality should be working Take a screenshot and attach or copy/paste the output.

Review:

• [ ] code approved by
• [x] tests executed by pytest. Actually this time.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 84.56%. Comparing base (a7485ad) to head (a294c9a). Report is 1 commits behind head on main.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #4853 +/- ## ========================================== + Coverage 84.17% 84.56% +0.38% ========================================== Files 318 318 Lines 19276 19276 ========================================== + Hits 16226 16301 +75 + Misses 3050 2975 -75 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[dnil]

I have changed my mind: BASIC and assembler were a lot cleaner.

[dnil]

You would think that the test discovery would work the same way if you run it on a parent directory or grandparent directory as well... 🫠

You would also think that tests, with functions named test, in a super-folder named tests, given explicitly to pytest when starting the test (and that run if you give the subfolder name) would run by default. No. You have to name every file in the whole directory tree something that begins or ends with "test". Was this developed by Microsoft?

[dnil]

Anyway.

[northwestwitch]

No. You have to name every file in the whole directory tree something that begins or ends with "test".

I knew actually. That's why in general when I'm developing I call the single test specifically introducing an error so I know if it runs or not. It fooled me already 😆

[dnil]

Hehe, I see. Calling the single test or subdirectories works even if running on the top level dir doesn't. I do already locally just to save time. You mean you actually run the whole test barrage with an error once for every new test?

One might also take into consideration the oaf-ness of the guy who sees a huuuuge tree with files named "test_*.py" and decides it would be a good idea to introduce the first one that doesn't. 😆

[northwestwitch]

Hehe, I see. Calling the single test or subdirectories works even if running on the top level dir doesn't. I do already locally just to save time. You mean you actually run the whole test barrage with an error once for every new test?

No like, I create the test and inside I write something like: assert "BLABLA" == "BLEBLE" and see if I get the error. Just once by calling my specific test.

[dnil]

Hehe, I see. Calling the single test or subdirectories works even if running on the top level dir doesn't. I do already locally just to save time. You mean you actually run the whole test barrage with an error once for every new test?

No like, I create the test and inside I write something like: asset "BLABLA" == "BLEBLE" and see if I get the error. Just once

Ah on GitHub actions? Gotcha, good practice.

[northwestwitch]

Ah on GitHub actions? Gotcha, good practice.

no, locally

[dnil]

Ah on GitHub actions? Gotcha, good practice.

no, locally

But that takes like 40 mins?! Well, I can run local parallel as well, but still a few mins.

[northwestwitch]

But that takes like 40 mins?!

Nope, just my test

[northwestwitch]

But that takes like 40 mins?!

Nope, just my test

But I think I also run all tests once per PR. Same time as I develop somewhere else. Locally I mean. Or if I'm on servers I run tests on all the servers dir

[dnil]

But that takes like 40 mins?!

Nope, just my test

Both

pytest tests/server/blueprints/omics_variants/omics_variants.py::test_filter_export_omics_variants

and

pytest tests/server/blueprints/omics_variants

work just fine... 🫠 Just not only

pytest

[dnil]

But that takes like 40 mins?!

Nope, just my test

But I think I also run all tests once per PR. Same time as I develop somewhere else. Locally I mean. Or if I'm on servers I run tests on all the servers dir

Sure, same, but I would not notice the omission of one new test there without like as you suggested an expected assert error in there! Anyway, not the nicest mechanism, though one could kind of infer the idea from looking at a hundred examples. >XD

[sonarcloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud