Blank metadata download

[jameshadfield]

Current Behavior
For some datasets or zoom levels, the downloaded per-strain metadata is a file with one line:

strain

Expected behavior
The downloaded metadata should reflect all strains currently selected (i.e. in the header, "Showing X of Y genomes").

How to reproduce
Steps to reproduce the current behavior:

Will add soon

Your environment: if browsing Nextstrain online

• Operating system: MacOS
• Browser: Firefox 92.0
• Auspice 2.31.0

Additional context

• May be related to datasets without time.
• Seems to be stochastic

[corneliusroemer]

I've just encountered this bug, too. It's definitely highly selective in when it happens. This is the tree where it occured:
https://nextstrain.org/groups/neherlab/ncov/global?branchLabel=aa&c=gt-ORF1b_1918&f_clade_membership=21A%20%28Delta%29&f_pango_lineage=AY.30&m=div

This is a screenshot where one can see the issue with 0 authors:

It may have something to do with cache? The download seems to have been called a different name than the new dataset. I saw the date as being 30th of September, when the current file is from 4th of October. And I just updated over the last half hour or so. Maybe this helps you finding the bug @jameshadfield

[corneliusroemer]

Edit: I looked up web requests and the metadata seems already downloaded, so this failure mode is implausible now.

Now that I've thought a bit more about the issue, I'm pretty sure I've come up with one failure mode. Steps to reproduce (haven't done myself - but seems like a plausible hypothesis for me):
1. Load a nextstrain.org auspice in browser
2. Update dataset by using nextstrain deploy (try out two different scenarios: a) URL stays same but strains change, b) URL stays same and strains stay same)
3. Try metadata download
4. Observe results

The failure is that auspice makes a query to the server for something that no longer exists. Rather than throwing an error to the user, it fails silently, confusing the user.

[corneliusroemer]

Just have this happening again - very weird. Sometimes download is empty now (usually not the first download, but after browsing around) - sometimes it's the tips that were previously highlighted (before I zoomed out via minus lens)

[corneliusroemer]

Hah, I can reproduce it on this tree: https://next.nextstrain.org/fetch/genome.ucsc.edu/trash/ct/subtreeAuspice1_genome_2ff8b_f80b50.json?label=id:node_6763511

This node produces proper download:

But this node results in empty download:

I'll download the tree as it is not permanently saved by Usher (just delete the .txt, it's required for upload to Github):
subtreeAuspice1_genome_2ff8b_f80b50.json.txt

Here are some of the logs, not sure if this is helpful:

Steps:

1. Load tree
2. Navigate to the first branch
3. Download
4. Observe that it's a 19kB metadata file
5. Navigate to second branch
6. Download and observe empty file
7. Navigate to first branch
8. Download and observe it's the same 19kB again
   @jameshadfield

[corneliusroemer]

I think I know what the issue is: it's a bug to do with the label=id:node_6763511 parameter!

Here's what I found:

For some reason, when you open a tree with that label parameter, metadata will only ever output tips that are below the node that you loaded the tree with. So if you download metadata for that internal node, or any child node, all is fine.

However, as soon as you zoom out, you stop getting extra metadata, you will only ever get at most what's below that node (zoom out and observe that the file size remains the same). When you zoom to a different internal node that doesn't have the initial node as a child, this results in the intersection being empty, hence the empty metadata download.

[joverlee521]

Wow, nice find @corneliusroemer! I am able to reproduce the bug by loading any tree with the label query param.

The reason the nodes are being excluded in the metadata download is because the node.inView values are False and therefore skipped instrainTSV.

Now to trace down why the inView values are not getting updated when you zoom out.

[joverlee521]

Hmm, @jameshadfield I will need a refresher on node.inView vs node.shell.inView.

When clicking on "Reset Layout", updateVisibleTipsAndBranchThicknesses gets dispatched and calls on applyInViewNodesToTree. From what I can tell, this always sets the node.shell.inView property because I'm not sure when tree.nodes[0].shell is ever a falsy value.

The metadata download only checks the node.inView property but not node.shell.inView, so it's skipping the nodes even though they are marked as visible in node.shell.inView.