Closed northwestwitch closed 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:
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
And its not just that one of them has no aa change?
Perhaps, I'll try to remove it from TECR in the demo case
I haven't tested, just clicked the link once, so more on the hunch level than usual... ๐
No but also the demo case has the aa change in only one gene. ๐
Sorry, I compared to your test, not the live one! :+1:
dbSNP then?
The weird thing is that the javascript alert complains for the dbsnp id, that is missing in both cases!
And it doesn't work even if you provide a fake dbSNP id (like rs1111)
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?
Like especially the updated classification events?
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 button
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)
Like here:
Time for some tests for these perhaps? ๐
There' s a difference here, looking at the HTML source:
The one NOT working:
the one that is working:
Yes, because it is ad_dn; see above! :)
Blame for that will show who searched-and-replaced Sex in the code? ๐
Blame for that will show who searched-and-replaced Sex in the code?
Right??? ๐
OF we reintroduce Sex it should work then. I'll fix a test with the demo! Thanks for the help
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?
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
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.
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?
From the bright side, we found one bug at least. Thats something.. ๐
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.
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
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?
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.
Ah, but you could now generate a new one with cg , with like --dryrun or whatever to just get the config without loading it.
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.
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!
I've suggested the user to create the ClinVar files using the scout stage case instead, since it works.
Did it work? If so we can perhaps close this and reopen if it happens again / can be reproduced?
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
There is something odd in this variant for instance:
https://scout.scilifelab.se/cust003/15001/52b97af467ec8966f6fb497b1aedb79a