Synonymized taxa in induced subtree

[snacktavish]

From digging into bomeara's question on gitter- I realized that our API docs induced_subtree example isn't working.

https://github.com/OpenTreeOfLife/germinator/wiki/Synthetic-tree-API-v3#induced_subtree

The problem appears to be that one of the id's 'ott666014' has been synonymized with 'ott285198'
https://tree.opentreeoflife.org/taxonomy/browse?id=666104

This means this while the taxon that 'ott666014' refers to does appear in the synthetic tree, the node in the synthetic tree it refers to does not have that node id.

[bredelings]

So is the problem that when we use a synonym in the query, the answer uses the canonical name?

[snacktavish]

Not exactly - I think it is that via the taxonomy browser ott666104 resolves to ott285198, (Setophaga) but that doesn't happen in induced subtree search. I think the problem is that because the query uses the alternate id, it doesn't find the node, even that taxon is in the tree under another id.

so this works:

     curl -X POST https://api.opentreeoflife.org/v3/tree_of_life/induced_subtree-H "content-type:application/json" -d '{"ott_ids":[292466, 267845, 666104]}'

and this doesn't:

 curl -X POST https://api.opentreeoflife.org/v3/tree_of_life/induced_subtree-H "content-type:application/json" -d '{"ott_ids":[292466, 267845, 285198]}'

But I'm not sure more broadly how we want to handle taxa can can be referred to by different ottids (or if that should even happen at all).

[bredelings]

So, what we need to do is to

• not treat forwarded taxa as missing
• add a map from the query name to the canonical name

[mtholder]

re-uppping this. still in our API docs

[snacktavish]

Ha, I just ran into this same issue again, in Setophaga specifically!
It appears that this is also causing issues in custom synth, and maybe in synth more generally.

Taxa in this tree are all mapped
https://tree.opentreeoflife.org/curator/study/view/pg_2591?tab=home&tree=tree6024&node=node1032246
e.g.
https://github.com/OpenTreeOfLife/phylesystem-1/blob/master/study/pg_91/pg_2591/pg_2591.json#L534
But they are mapped to an older ottid that her been merged
e.g.
https://tree.opentreeoflife.org/taxonomy/browse?id=3597209
https://tree.opentreeoflife.org/taxonomy/browse?id=532751

This is causing the conflict viewer on the tree to behave oddly (compare to synth in Setophaga).

But more importantly - in running custom synth, I think no information is carried through to synthesis for 532751 as the tip is mapped to 3597209. Which I guess is pruned?
(hacky demo script here: https://github.com/McTavishLab/OpenTreeCLO/blob/main/scripts/custom_synth_mystery.py)

@mtholder any thoughts?