Clinical-Genomics / scout

VCF visualization interface
https://clinical-genomics.github.io/scout
BSD 3-Clause "New" or "Revised" License
152 stars 46 forks source link

ClinVar submission doesn't work for a specific variant #2322

Closed northwestwitch closed 3 years ago

northwestwitch commented 3 years ago

There is something odd in this variant for instance:

https://scout.scilifelab.se/cust003/15001/52b97af467ec8966f6fb497b1aedb79a

northwestwitch commented 3 years ago

Working on this. I'm trying to reproduce it in a test environment by adding another gene to the variant, but in this case it works!

This could could give an indication of what's wrong anyway:

image

northwestwitch commented 3 years ago

It's not a matter of double gene because another variant hitting the same two genes works: https://scout-stage.scilifelab.se/cust003/20192/25e253c05b52241bc18c64f9dd336f45/clinvar

dnil commented 3 years ago

And its not just that one of them has no aa change?

northwestwitch commented 3 years ago

Perhaps, I'll try to remove it from TECR in the demo case

dnil commented 3 years ago

I haven't tested, just clicked the link once, so more on the hunch level than usual... ๐Ÿ˜Š

northwestwitch commented 3 years ago

No but also the demo case has the aa change in only one gene. ๐Ÿ˜•

dnil commented 3 years ago

Sorry, I compared to your test, not the live one! :+1:

dnil commented 3 years ago

dbSNP then?

northwestwitch commented 3 years ago

The weird thing is that the javascript alert complains for the dbsnp id, that is missing in both cases!

northwestwitch commented 3 years ago

And it doesn't work even if you provide a fake dbSNP id (like rs1111)

dnil commented 3 years ago

In the spirit of random guessing: next row then is a classification, and the non-working one has some ACMG stuff. Anything there that might interact?

dnil commented 3 years ago

Like especially the updated classification events?

northwestwitch commented 3 years ago

I've classified the demo one in the same way and still works, so it shouldn't be that. I'm starting to think that is not something in the form you see, but something that fails in the form that is displayed immediately after when you click image button

dnil commented 3 years ago

Or like the rows before: the non-working appears to have a slightly broken option for the selection for AR_hom, which it is: (L188-189)

dnil commented 3 years ago

Like here:

https://github.com/Clinical-Genomics/scout/blob/575a72659254783df1cc36090beb220441d62360/scout/server/blueprints/variant/templates/variant/clinvar.html#L188

Time for some tests for these perhaps? ๐Ÿ˜Š

northwestwitch commented 3 years ago

There' s a difference here, looking at the HTML source:

The one NOT working: image

the one that is working: image

dnil commented 3 years ago

Yes, because it is ad_dn; see above! :)

dnil commented 3 years ago

Blame for that will show who searched-and-replaced Sex in the code? ๐Ÿ˜‰

northwestwitch commented 3 years ago

Blame for that will show who searched-and-replaced Sex in the code?

Right??? ๐Ÿ˜†

northwestwitch commented 3 years ago

OF we reintroduce Sex it should work then. I'll fix a test with the demo! Thanks for the help

northwestwitch commented 3 years ago

I'm a bit confused, because if you take any other variant with inheritance AR_hom then it works. Perhaps a combo 2 genes/ar_hom inheritance?

northwestwitch commented 3 years ago

No, it works also with 2 genes, check this one: https://scout-stage.scilifelab.se/cust002/F0015031/80f883dbc7594641c2dc2ce7f35c5c03

I start to think that the misspelled inheritance pattern was a bug, but not THE bug causing the problem described in this issue

northwestwitch commented 3 years ago

This bug might be my worst nightmare. I still don't understand what the cause is and the strangest thing if that I can't reproduce it. I've even tried to create a local dummy case with exactly that variant taken from that case. I've assigned the same acmg classification and when I try to create the submission it just works, as if nothing is wrong with it.

dnil commented 3 years ago

Hm, and I guess nowhere I can try to replicate either really?! Copying the db record of the variant would have been my next move as well.

Have you unassigned, changed and reassigned? There had been a few event updates, but maybe you replicated them as well. And that is really just interesting due to being nearby - seems just as likely with sth else on the same page, if it is not that dbsnp id directly. No error messages in the server logs?

dnil commented 3 years ago

From the bright side, we found one bug at least. Thats something.. ๐Ÿ˜†

northwestwitch commented 3 years ago

It doesn't look like it cares about the actions you do (assig, reassign, mark pathogenic, change, etc) and it doesn't complain about anything in the logs.

northwestwitch commented 3 years ago

To try to replicate it one could load the case on stage with no research variants and the load the research variants in that interval. Then from stage one could try to log messages here and there to see where the problem is

dnil commented 3 years ago

Riiight, its a research variant. I didn't even notice. ๐Ÿ˜† Hm, yeah there like tons of places where that could go wrong e.g. with variant ids / simple ids being switched up on lookups. Then I suppose you already ran a few tests with classifying and submitting different research variants.. What if there is some old stuff on that case, like from before we fixed a thing or two with research ids vs clinical ids?

northwestwitch commented 3 years ago

The same variant is present among the non-research variants, and if you try the clinvar submission on this one using scout prod it fails as well. I don't know if there is weird stuff on that case, but the scout config file is missing so it's a pain also if you want to upload it on stage.

dnil commented 3 years ago

Ah, but you could now generate a new one with cg , with like --dryrun or whatever to just get the config without loading it.

northwestwitch commented 3 years ago

I've successfully uploaded the case on stage (the old one didn't have this variant). The variant is present and the clinvar submission works fine: https://scout-stage.scilifelab.se/cust003/15001/01fc608966a1fb60233a119eb651de00

At this point I am almost sure that if we reupload the case in production it will work as well. We might have changed something in this case during the years and the reruns perhaps, possibly even touching directly the database, and that might have caused this bug.

dnil commented 3 years ago

Yeah, that was certainly on the table. "En gรฅng รคr ingen gรฅng" - right? Lets keep a lookout, but this at least fixed a couple of other hitherto unknown issues. Fingers crossed for the re-up!

northwestwitch commented 3 years ago

I've suggested the user to create the ClinVar files using the scout stage case instead, since it works.

dnil commented 3 years ago

Did it work? If so we can perhaps close this and reopen if it happens again / can be reproduced?

northwestwitch commented 3 years ago

Did it work? If so we can perhaps close this and reopen if it happens again / can be reproduced?

She created the submission manually the day before we worked on this so this specific issue doesn't need any fixing. Let's close and reopen if the problem persists on other variants as well