Fixup: View in other platforms -> Nextclade -> Run -> Error: null pointer passed to rust

[j23414]

Current Behavior

From the Dengue Auspice view, at the bottom of the screen, click "View in Other Platforms", "Nextclade" and use example sequences from Dengue, and hit run:

Expected behavior

Should be able to call dengue lineages from the live trees

How to reproduce

Steps to reproduce the current behavior:

1. Open https://next.nextstrain.org/dengue/all/genome [Edit: 2025-03-19] https://next.nextstrain.org/dengue/all/genome@2025-03-03
2. Navigate to the bottom of the screen and click "View in Other Platforms"
3. Click "Nextclade"
4. From "Nextclade" select example sequences from "dengue/all"
5. Hit Run
6. View error

Possible solution

Might need to update the nextclade fields in auspice.json

Your environment: if browsing Nextstrain online

• Operating system: MacOS
• Browser: Chrome

Your environment: if running Nextstrain locally

• Operating system:
• Browser:
• Version (e.g. auspice 2.7.0):

Additional context

Add any other context about the problem here.

[victorlin]

I'm getting a different error:

Error text for searchability

When initializing Nextclade runner: When preprocessing Nextclade graph: When retrieving aa mutations from reference tree node NODE_0000352: Encountered a mutation (X64S) in reference tree branch attributes, for which the origin state of the mutation is inconsistent with the state at the parental branch. Mutations origin state is 'X', but tree (inferred from the reference sequence as no prior mutations were observed at this position) has state '*'. This is likely an inconsistency between reference tree and reference sequence in the Nextclade dataset. Reference sequence should either correspond to the root of the reference tree or the root of the reference tree needs to account for difference between the tree and reference sequence. Please check that your reference tree is consistent with your reference sequence.

The official nextstrain/dengue/all dataset shows the same error if it is loaded directly from the "view in other platforms" link. It only works on a fresh Nextclade instance. Here's a video explanation:

dengue-dataset-error.mov

This last part seems like a bug with Nextclade web. cc @ivan-aksamentov

[ivan-aksamentov]

Oh no! That's not good!

There are 2 separate problems I think.

Problem 1, shown by @victorlin:

I can repro the error. This is highly likely a problem in data. I conducted a small experiment, but only the dataset authors can confirm my conclusion:

Download Auspice json:

$ curl -o dengue_all_genome.json -fsSL -H 'Accept: application/vnd.nextstrain.dataset.main+json;q=1, application/json;q=0.9, text/plain;q=0.8, */*;q=0.1' 'https://next.nextstrain.org/dengue/all/genome'

Is there a root sequence on the tree (required)?

$ jq -r '.root_sequence.nuc | .[:200]' dengue_all_genome.json 
AGTTGTTAGTCTACGTGGACCGACAAGAACAGTTTCGACTCGGAAGCTTGCTTAACACAGTTCTAATAGTTTGTTTAATTAGAGAGCAGATCTCTGGGATGAACAACCAACGGAAAAAGGCGGGTAGACCGCCTTTCAATATGCTGAAACGCGCGAGAAACCGCGTATCAACCATATAACGGTTGGCGAAGAGATTCTCA

Yes (first 200 chars shown)

It does not seem to be the same sequence compared to Nextclade dataset here: https://github.com/nextstrain/dengue/blob/5b2ab4b5460436d5406cbf5daea87e8d2a1de2c4/nextclade/datasets/all/reference.fasta. This is not necessarily a problem -if the Nextclade dataset (folder) and Auspice dataset (json) are meant to be separate things. But if not, might also signify some confusion between files, notably ref sequences, and whether the root/ref relations are correctly preserved (read below). I don't know the author's intent, so cannot tell. Was the plan that auspice json and nextclade dataset based on the same ref? If at some point one of them diverged, perhaps nextclade bits in auspice dataset have not been updated properly, because nextclade dataset works and auspice dataset does not.

Are mutations between root node and ref sequence attached to root node?

$ jq -r '.tree.branch_attrs' dengue_all_genome.json 
{
  "mutations": {}
}

No.

There are no mutations attached to the root node. In this situation the root node's sample (given to augur when constructing the tree) is assumed to be exactly the same as the reference sequence (provided in .root_sequence.nuc). If this assumption does not hold, Nextclade's analysis will be bogus. The software tries to protect users from that, if it detects mutation mismatches as it traverses the tree and accumulates mutations, it reports that by showing the error Victor has found.

Also note, that the mutations from X (unknown aminoacid) like X64S and it allegedly being inconsistent with mutation to * (stop codon) are a bit suspicious. Something could be messed up on the tree. The samples could be of questionable quality and this makes both the auspice analysis and nextclade analysis somewhat less useful. Which is again, not necessarily a problem by itself (especially if seq data is scarce), but something to consider in the investigation.

Because the problem seem to be in aminoacid mutations, it could also be that the genome annotation is incorrect. For example, it does not matches the tree or reference sequence. In the auspice-json-as-nextclade-dataset mode, Nextclade retrieves annotation from .meta.genome_annotations of the json.

Let's check out the annotation (click to expand)

$ jq -r '.meta.genome_annotations' dengue_all_genome.json

{
  "nuc": {
    "end": 10649,
    "start": 1,
    "strand": "+",
    "type": "source",
    "seqid": "defaults/all/reference.gb"
  },
  "2K": {
    "end": 6827,
    "seqid": "defaults/all/reference.gb",
    "start": 6759,
    "strand": "+",
    "type": "CDS"
  },
  "C": {
    "end": 440,
    "seqid": "defaults/all/reference.gb",
    "start": 102,
    "strand": "+",
    "type": "CDS"
  },
  "E": {
    "end": 2423,
    "seqid": "defaults/all/reference.gb",
    "start": 939,
    "strand": "+",
    "type": "CDS"
  },
  "M": {
    "end": 938,
    "seqid": "defaults/all/reference.gb",
    "start": 441,
    "strand": "+",
    "type": "CDS"
  },
  "NS1": {
    "end": 3479,
    "seqid": "defaults/all/reference.gb",
    "start": 2424,
    "strand": "+",
    "type": "CDS"
  },
  "NS2A": {
    "end": 4133,
    "seqid": "defaults/all/reference.gb",
    "start": 3480,
    "strand": "+",
    "type": "CDS"
  },
  "NS2B": {
    "end": 4523,
    "seqid": "defaults/all/reference.gb",
    "start": 4134,
    "strand": "+",
    "type": "CDS"
  },
  "NS3": {
    "end": 6377,
    "seqid": "defaults/all/reference.gb",
    "start": 4524,
    "strand": "+",
    "type": "CDS"
  },
  "NS4A": {
    "end": 6758,
    "seqid": "defaults/all/reference.gb",
    "start": 6378,
    "strand": "+",
    "type": "CDS"
  },
  "NS4B": {
    "end": 7562,
    "seqid": "defaults/all/reference.gb",
    "start": 6828,
    "strand": "+",
    "type": "CDS"
  },
  "NS5": {
    "end": 10262,
    "seqid": "defaults/all/reference.gb",
    "start": 7563,
    "strand": "+",
    "type": "CDS"
  },
  "pr": {
    "end": 713,
    "seqid": "defaults/all/reference.gb",
    "start": 441,
    "strand": "+",
    "type": "CDS"
  }
}

If dataset authors can confirm that the root/ref assumption holds and annotation data is correct, then this is a bug in Nextclade and me and Richard will have to investigate it more closely.

See: https://docs.nextstrain.org/projects/nextclade/en/stable/user/input-files/04-reference-tree.html, paragraph "The tree must be rooted at the sample that matches the reference sequence."

[ivan-aksamentov]

For the second problem, the one that @j23414 originally reported - this is likely something else (or additional to).

First of all, this is 100% a bug, because Nextclade should never crash like that. This error message is a (poor) way for wasm-bindgen internals to say that Rust code panicked somewhere. A decent program must never panic. This code needs to be found and the error should be handled gracefully or fixed definitively if possible.

Unfortunately I am not able to reproduce it. I appreciate if you can give me some more information on how to reproduce the problem on my computer. Notably, perhaps the tree being fetched is not the same that I am fetching (see curl command in the previous post), for example because it was updated since the issue was reported. Or there might be an existing state in Nextclade Web UI which I don't have (e.g. a dataset selected or some other settings are modified in Nextclade in the same browser window, before the "How to reproduce" flow starts). Or input sequences might not be the same? (perhaps there are some leftovers from previous run?) once reproduced I could do some debugging. Without consistent repro it is virtually impossible for me to do anything.

I want Nextclade to be crash-free. So if you manage to crash it, ever, please ping me very loudly on GitHub or on Slack.

[rneher]

Yes, the problem @victorlin stumbled on has to do with augur translating TAA as X while Nextclade correctly translates it to *. This results in a mismatch between the mutation annotation and the translations by nextclade. This is why it is advisable to have use a sequence as root that is a real virus with functional proteins. So we should fix this on the dataset side, though it is hard to pick a good root for a diverse set like dengue.

[j23414]

Reproducing the null pointer error

Thanks for taking a look! I'm still reading the above comments, but just mentioning that I can reproduce the null pointer passed to rust error with the tree a couple weeks ago at:

• https://next.nextstrain.org/dengue/all/genome@2025-03-03

I'm running on Mac, Chrome. Sorry I should have included the date in the url

Error message: Error: null pointer passed to rust

Nextclade version 3.10.2 (commit: c14fb09, branch: release)

Memory available: 3586 MBytes

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36

Browser details: {"browser":{"name":"Chrome","version":"134.0.0.0"},"os":{"name":"macOS","version":"10.15.7","versionName":"Catalina"},"platform":{"type":"desktop","vendor":"Apple"},"engine":{"name":"Blink"}}

Call stack:

Error: null pointer passed to rust
    at $ (https://clades.nextstrain.org/_next/static/chunks/68.e9d379293394a9c7.js:1:10840)
    at https://clades.nextstrain.org/_next/static/wasm/cf7600370f973292.wasm:wasm-function[3897]:0x31acbb
    at https://clades.nextstrain.org/_next/static/wasm/cf7600370f973292.wasm:wasm-function[3898]:0x31acc8
    at https://clades.nextstrain.org/_next/static/wasm/cf7600370f973292.wasm:wasm-function[2156]:0x2c73fb
    at e.value (https://clades.nextstrain.org/_next/static/chunks/68.e9d379293394a9c7.js:1:4613)
    at https://clades.nextstrain.org/_next/static/chunks/68.e9d379293394a9c7.js:1:17594
    at u (https://clades.nextstrain.org/_next/static/chunks/444.170c49d0571b2ba1.js:1:28086)
    at Generator._invoke (https://clades.nextstrain.org/_next/static/chunks/444.170c49d0571b2ba1.js:1:29376)
    at a.<computed> [as next] (https://clades.nextstrain.org/_next/static/chunks/444.170c49d0571b2ba1.js:1:28489)
    at p (https://clades.nextstrain.org/_next/static/chunks/68.e9d379293394a9c7.js:1:14701)

Component stack:

N/A

But the current tree does indeed gives me the same error as Victor's post, so not sure if it's high priority since the latest tree has a different error.

[j23414]

Rooting the live builds of diverse viruses - perhaps with an outgroup?

augur translating TAA as X while Nextclade correctly translates it to *. This results in a mismatch between the mutation annotation and the translations by nextclade. This is why it is advisable to have use a sequence as root that is a real virus with functional proteins.

I was considering rooting the live dengue all-serotype tree on an outgroup Japanese Encephalitis virus (JEV). Do you think the outgroup rooting on a real JEV viral sequence would fix this or just result in further complications?

On the other hand, for each of the serotype trees, I would root on an outgroup of a different serotype (e.g. root the denv3 on an denv4 sequence). I have a simple path forward to outgroup rooting since this Augur PR.

[j23414]

Nextclade dataset and Auspice dataset parity

This is not necessarily a problem -if the Nextclade dataset (folder) and Auspice dataset (json) are meant to be separate things. But if not, might also signify some confusion between files, notably ref sequences, and whether the root/ref relations are correctly preserved (read below). I don't know the author's intent, so cannot tell. Was the plan that auspice json and nextclade dataset based on the same ref?

Just noting that the Nextclade dataset (folder) and the Auspice dataset (json) are intended to be separate, and supporting both would be a "nice-to-have" rather than a "must-have."

• The Nextclade dataset provides a curated tree (with a specified root and reference) for clade assignment. It needs to be of high quality for classification and undergoes more rigorous testing. As its primary purpose is classification rather than serving as a live summary of diversity, this can sometimes result in strange looking scaffold trees as seen here for the sake of lineage classification.

• The Auspice dataset (with a link-out to Nextclade) allows users to place their samples on the most up-to-date tree. However, its focus is on providing an updated tree view rather than classification. The zoom-in of the tree topology is more important here.

That said, this does highlight for me that perhaps we should aim for parity of root/reference for both the Nextclade and Auspice datasets across our pathogen workflows.

[ivan-aksamentov]

@j23414 Thanks, I can repro the crash. Made an issue nextstrain/nextclade#1590. Will try to debug and fix. I think it's still important, because Nextclade should never crash like that.

Also, agree with your assessment of Nextclade dataset vs Auspice dataset purpose and functionality. This makes sense.

[ivan-aksamentov]

The crash on the @2025-03-03 tree json was resolved in nextstrain/nextclade#1591 (will release next week; now available on master: web, cli). The problem was that .root_sequence.nuc of the tree JSON has a gap at position 2984. The implemented fix is to disallow gaps in ref sequences from now on. This fixes the crash by replacing it with a more useful error, but this does not fix the fact that the dataset won't run. This requires rebuilding the tree with gap-less reference sequence.

To try it: https://master.clades.nextstrain.org/?dataset-json-url=https://next.nextstrain.org/dengue/all/genome@2025-03-03