load_gff3 miscalculates CDS

[mpoelchau]

Hi Apollo team,

We are trying to use the python-apollo arrow annotations load_gff3 command to load annotations to the user-created annotations track. It is changing the CDS locations of the model, both with and without the --disable_cds_recalculation option.

Here is what a load without --disable_cds_recalculation looks like; the correct frame can be seen in the track below.

The gff3 that was used to load the annotation has 6 CDS lines; the gff3 for the uploaded annotation has 12 CDS lines (even though the view shows only one CDS segment). Apollo also won't calculate a protein or CDS sequence on the uploaded annotation.

Here is what a load with --disable_cds_recalculation looks like (command: arrow annotations load_gff3 --source https://apollo2-stage-node1-cbo.nal.usda.gov/apollo Anoplophora_glabripennis ~/Downloads/NW_019416298.gff3 --disable_cds_recalculation)

Again, the gff3 for the uploaded annotation in Apollo has 12 CDS lines instead of 6. Apollo also won't calculate a protein or CDS sequence on the uploaded annotation.
I'll note that if you run the same command multiple times, the single CDS will display in a different spot each time.

If you load the annotation by dragging it up, it loads correctly:

This is happening for many (but not all) annotations in multiple assemblies/organisms.

Some other observations:

• We haven't observed the problem for models with a single CDS/exon segment
• The underlying genomic sequence has lowercase nucleotides
• I tried using load_legacy_gff3, and that calculated the CDS correctly, but I'm unable to delete features when I load them with that method (Hibernate operation: could not execute statement; SQL [n/a]; ERROR: update or delete on table "feature" violates foreign key constraint "fk_8jm56covt0m7m0m191bc5jseh" on table "feature_relationship" Detail: Key (id)=(4858111) is still referenced from table "feature_relationship".; nested exception is org.postgresql.util.PSQLException: ERROR: update or delete on table "feature" violates foreign key constraint "fk_8jm56covt0m7m0m191bc5jseh" on table "feature_relationship" Detail: Key (id)=(4858111) is still referenced from table "feature_relationship".)

I've attached "before" and "after" gff3s. (Used .txt extension because GitHub wouldn't let me upload otherswise)
before.txt
after-nocdsrecalc.txt
after.txt

• Provide the javascript console log output generated from the action.
  None.

• Provide the server log output generated from the action (typically catalina.out).
  nothing is added to Catalina.out when I add the annotations.

[garrettjstevens]

Hi @mpoelchau. arrow is actually developed and maintained by a separate group, so you'll need to file an issue in that repository here: https://github.com/galaxy-genome-annotation/python-apollo.

[mpoelchau]

Thanks @garrettjstevens, I'll repost there. I posted here because I assumed that the python method was essentially a wrapper around the apollo add_transcript method, but you know what they say about assumptions...

Is there an alternate method maintained by the Apollo group to load gff3s into the UcA?

[garrettjstevens]

There's not an official method for loading GFF3s that we maintain. However, if there's some way to get the log from arrow of what requests are sent to the Apollo endpoint, I'd be happy to look at those and see if anything looks off.

[MonicaPoelchau-USDA]

Thanks @garrettjstevens ! I attached the output to a comment in the other issue: galaxy-genome-annotation/python-apollo#60 (comment). The only other output that the command issues is the following warning (it does this for all arrow commands):
/Users/mpoelchau/Documents/programs/apollo-arrow-env/lib/python3.9/site-packages/urllib3/__init__.py:34: NotOpenSSLWarning: urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with 'LibreSSL 2.8.3'. See: https://github.com/urllib3/urllib3/issues/3020