genes2transcripts output was altered and all interactions now fail

[ifokkema]

Describe the bug
The genes2transcripts output was altered, and all interactions now fail.

Until now, LOVD3 allowed using VV to retrieve transcripts for a gene as a backup of the existing Mutalyzer feature, which has increasingly been failing. I've been putting off the work needed to remove Mutalyzer altogether, but I'm now in the process of doing so. However, to my surprise, the VV feature to fetch transcripts no longer worked because the API's output was changed recently. I can't be sure which commit caused this, as I'm unfamiliar with VV's internal structure, but the whole response is now wrapped into an otherwise empty list. I can only assume this concerns #515 and #516. If I had done the work earlier, this would have broken all LOVD instances worldwide.

Although a genes2transcripts_v2 endpoint suggests that some form of versioning is now in use, I must stress again never to change existing API output (although adding fields to an existing API structure would be acceptable, in my opinion). Tests must be in place to ensure that existing API endpoints don't lose existing fields or, in this case, even return a completely different type of variable (from object to list).

To Reproduce
Steps to reproduce the behavior:

1. This URL: https://rest.variantvalidator.org/VariantValidator/tools/gene2transcripts/HGNC%3A48626?content-type=application%2Fjson
   Used to return an object:

{
  "current_name": "CHD2 adjacent suppressive regulatory RNA",
  "current_symbol": "CHASERR",
  "hgnc": "HGNC:48626",
  "previous_symbol": "LINC01578",
  "requested_symbol": "CHASERR",
  "transcripts": [
    {
      "annotations": {
        "chromosome": "15",
        "db_xref": {
          "CCDS": null,
          "ensemblgene": null,
          "hgnc": "HGNC:48626",
          "ncbigene": "100507217",
          "select": false
        },
(etc.)

However, it now returns a list:

[
  {
    "current_name": "CHD2 adjacent suppressive regulatory RNA",
    "current_symbol": "CHASERR",
    "hgnc": "HGNC:48626",
    "previous_symbol": "LINC01578",
    "requested_symbol": "CHASERR",
    "transcripts": [
      {
        "annotations": {
          "chromosome": "15",
          "db_xref": {
            "CCDS": null,
            "ensemblgene": null,
            "hgnc": "HGNC:48626",
            "ncbigene": "100507217",
            "select": false
          },
(etc.)

2. This leads to a complete failure to retrieve on LOVD's side.

Expected behavior
Since I'll need to continue development, I'll add a workaround in the LOVD3 code. Related issue: LOVDnl/LOVD3#639
However, although I don't know how long this has been broken, I suggest restoring the original output to avoid breaking other implementations out there. Also, I believe the v1 of the endpoint isn't meant to process a list of genes anyway, so the list in the output doesn't apply altogether and will just confuse new users.

Note, I'm completely fine with a list as a return value for the v2 of the endpoint, and it makes sense there, as it allows for a list to be submitted.

[Peter-J-Freeman]

This is odd. I don't remember making the V1 version into a list output. It is the sort of breaking change we aviod. Leave it with me,

[Peter-J-Freeman]

@ifokkema , this was a change in VariantValidator not the API. Restoring old behavior

[Peter-J-Freeman]

This is fixed. Needs a server update now @ifokkema