bad tree structure error when moving Genus to a different Family

[grantfitzsimmons]

To recreate, attempt the following move:

The Taxon node "Arceuthobium" will be placed, along with all of its descendants, under the new parent "Loganiaceae".

Move Arceuthobium to the Loganiaceae Family.

https://aafcaacdao-edge.test.specifysystems.org/specify/tree/taxon/?conformation=%7E%7E1%7E181107%7E160131%7E160170--%7E159752----

Error occurred fetching from https://aafcaacdao-edge.test.specifysystems.org/api/specify_tree/taxon/160170/move/

Invalid response code 500. Expected 200.

This error may indicate a misconfiguration or a bug in Specify. Please double check your configuration and report this issue.

AssertionError at /api/specify_tree/taxon/160170/move/
bad tree structure

Request URL: http://aafcaacdao-edge.test.specifysystems.org/api/specify_tree/taxon/160170/move/

Reported By: HeatherC at the Community Forum

https://discourse.specifysoftware.org/t/error-in-s7-tree-moves/949/2

[grantfitzsimmons]

Specify 7 Crash Report - 2022-12-22T17_53_24.586Z.txt

[specifysoftware]

This issue has been mentioned on Specify Community Forum. There might be relevant details there:

https://discourse.specifysoftware.org/t/error-in-s7-tree-moves/949/5

[grantfitzsimmons]

Similar to #2707

Might have the same underlying issue

[melton-jason]

For this case, it looks like the tree is misconfigured. There is a tree node Cornus canadensis f. dutillyi (taxonid: 18574) which has a child which is the same rank as itself.
The child is Cornus canadensis f. viride (taxonid: 186086)

SQL Command:

select t.taxonid, p.taxonid, t.fullname, p.fullname, t.parentid, p.parentid, t.rankid, p.rankid from taxon t join taxon p on t.parentid=p.taxonid where t.rankid <= p.rankid;

Result:

+---------+---------+-----------------------------+-------------------------------+----------+----------+--------+--------+
| taxonid | taxonid | fullname                    | fullname                      | parentid | parentid | rankid | rankid |
+---------+---------+-----------------------------+-------------------------------+----------+----------+--------+--------+
|  186086 |   18574 | Cornus canadensis f. viride | Cornus canadensis f. dutillyi |    18574 |    18572 |    260 |    260 |
+---------+---------+-----------------------------+-------------------------------+----------+----------+--------+--------+

The problem taxa in specify 7 and its child:

https://aafcaacdao-edge.test.specifysystems.org/specify/tree/taxon/?conformation=%7E%7E1%7E181107%7E159752-%7E160131-%7E18522%7E18540%7E18572------

[grantfitzsimmons]

@melton-jason Specify 6 doesn’t throw an error when doing this action

[melton-jason]

I believe this is because the error is only thrown when validating node numbers in Specify 7. I don't believe the problem taxa are involved in any way with the two nodes being moved, so Specify 6 probably doesn't care about it.
Specify 7 checks the entire tree, hence the error.

[melton-jason]

What happens to Cornus canadensis f. viride after the move in 6? I would assume it would remain unchanged (as a child to Cornus canadensis f. dutillyi both with the rank of forma)

[specifysoftware]

This issue has been mentioned on Specify Community Forum. There might be relevant details there:

https://discourse.specifysoftware.org/t/error-in-s7-tree-moves/949/7

[melton-jason]

This has since been resolved by Heather C in the Speciforum at (https://discourse.specifysoftware.org/t/error-in-s7-tree-moves/949/8).

The only thing to potentially consider is how we want to handle tree checks like this one. Users may have a hard time solving an error like this because any tree action may result in Specify throwing the error once again (as shown in Heather's post).
If this is brought into consideration, it is probably more appropriate to open a new issue, so I am closing this one.

[maxpatiiuk]

@melton-jason could you improve the "bad tree structure" error to tell exactly which node is causing the problem?

That would serve well in the future

[melton-jason]

Yes, I have gone through and improved the messages for a few Assertion Errors in the backend in #2702, this one included. Very shortly I will push a commit that addresses this one in more depth, and the error message will display a list of all nodes (containing their taxonid and fullname) which caused this error.