Funannotate eggNOG multi-EC parsing can fabricate incorrect EC annotations

[highfield09]

Funannotate eggNOG multi-EC parsing can fabricate incorrect EC annotations

Summary

funannotate annotate v1.8.17 incorrectly reduces comma-separated EC annotations from eggNOG-mapper using Python's os.path.commonprefix().

The code describes this operation as a “least common ancestor approach”, but commonprefix() compares strings character-by-character rather than comparing the four hierarchical components of an EC number. As a result, a legitimate set of alternative EC annotations can be converted into:

• an invalid partial EC;

• an unjustifiably specific four-level EC;

• or a different, real EC number that has no biochemical relationship to the original alternatives.

The bug occurs in Funannotate's eggNOG parser, after eggNOG-mapper has produced its annotation field and before functional annotations are inserted into the NCBI feature table. It can therefore contaminate .tbl, GenBank-derived outputs and downstream metabolic reconstruction.

The core software bug is confirmed directly from the Funannotate source and repository history. The reported count of 81 affected genes across three genomes is dataset-derived and should be reported separately as requiring independent reproduction from the original *.emapper.annotations and Funannotate output files.

---

Environment in which the problem was observed

Component | Version -- | -- Funannotate | v1.8.17 eggNOG-mapper | emapper-2.1.13 Python | 3.8.19 Installation | Bioconda / conda Genomes | Kluyveromyces lactis, Yarrowia lipolytica, Geotrichum candidum

The bug mechanism is independently confirmed, but these counts cannot be verified from the Funannotate repository itself.

To make the 81-gene result fully reproducible, the audit should compare, per gene:

*.emapper.annotations
        ↓
annotations.eggnog.txt
        ↓
all.annotations.txt
        ↓
final .tbl
        ↓
final .gbk
        ↓
final .annotations.txt

and record the value at every transition.

Until that comparison is attached, the correct wording is:

“81 affected genes were identified in the three analysed datasets.”

rather than:

“The Funannotate bug universally affects 81 genes.”

---

Impact on downstream metabolic reconstruction

This defect is particularly important when Funannotate annotations are subsequently used for genome-scale metabolic reconstruction.

A corrupted EC can lead to:

correct orthology evidence
        ↓
wrong EC annotation
        ↓
wrong reference reaction association
        ↓
incorrect candidate metabolic reaction
        ↓
MILP/gap-filling selection
        ↓
chemically or biologically incorrect SBML

The MILP or reconstruction software may therefore propagate an annotation error that originated earlier; it does not necessarily create the incorrect EC itself.

However, this bug does not explain every incorrect EC/reaction association observed downstream.

For example, when eggNOG contains:

1.14.18.5,1.14.19.17

this Funannotate bug generates approximately:

1.14.1

not a specific:

1.14.19.17

Therefore, if a universal metabolic reaction later carries the fully specified 1.14.19.17, an additional downstream source or mapping decision must still be identified.

---

Conclusion

The central bug report is valid:

Funannotate incorrectly uses a character-level string-prefix function to perform what its source calls an EC-number “least common ancestor” operation.

This can destroy annotation ambiguity, generate malformed EC identifiers and, most seriously, fabricate valid but unrelated EC identifiers that can subsequently propagate through Funannotate's NCBI conversion and into downstream analyses.

The strongest corrections to the original interpretation are:

• issue eggnog v2 output is not being parsed correctly #566 did not report this specific bug; the problematic code was introduced in the parser work associated with that issue;

• tbl2asn, rather than modern table2asn, was invoked by Funannotate v1.8.17;

• current table2asn source confirms the general EC replacement/deletion mechanism but does not by itself prove the behaviour of the exact historical tbl2asn binary;

• NCBI diagnostics are not necessarily absent, although Funannotate suppresses tbl2asn stdout/stderr and performs no EC-specific validation itself;

• multiple eggNOG ECs should be treated as annotation evidence, not automatically as demonstrated multifunctionality;

• historical EC transfers must distinguish one-to-one from split transfers;

• the COQ1 example proves that the final 2.5.1.75 annotation is incompatible with the source enzyme-family evidence, but it does not alone determine whether 2.5.1.82, 2.5.1.83 or a broader 2.5.1.- is the correct fungal EC;

• and the reported 81-gene prevalence remains a dataset-level finding that should be independently reproduced from the original files.

Overall severity: high for functional annotation integrity where downstream workflows rely directly on Funannotate EC qualifiers.

[highfield09]

Hello team, thank you for the work and maintaining Funannotate.
Im relatively new to genomics (and computation in general) so I employ the help of Claude and Codex to understand certain things.
This bug report I felt i needed to generate when i noticed EC number truncations downstream that didnt seem to match and led me down a rabbit hole. This bug report was summarised and (i hope) verified by claude and codex and would like to know if its true for the eggNog component of Funannotate? Then I could make some post-annotation scripts to verify EC/product name assignments.

If the team has other recommendations in order to reduce the number of Product: hypothetical proteins counts in an annotation pipeline, that would be of great help.

[hyphaltip]

A lot of changes are on the 1.9 branch may need to see if that addresses these. I fixed some eggnog parsing there and some of the partial truncating regexp. Some of that might be on master branch but most of my current work are on a 1.9 branch that has some speed ups and fixes some of these things.

I generally remove EC prediction at this point I don't see them as helping at a NCBI submission stage.