Scout: Bug with pinned variants showing only id (not loaded error)

[hassanfa]

Image below is quite descriptive. Re-uploading might solve it, but what would've caused it?

https://scout.scilifelab.se/cust087/fitbeagle

[dnil]

Usually a re-upload where the variant is missing / filtered / not loaded the second time around. We'll check!

[northwestwitch]

Yes, might be that the VCF used in the reupload doesn't contain that variant any more

[dnil]

I smell non-standard, hands on operation. Seems to have been at least one re-upload (based on seeing comments flagged OLD) but no such entries in events. Also a comment saying that the case is now paired compared to tumor only? Perhaps it was previously uploaded as such with the same id?

[hassanfa]

Do you want to investigate? We can postpone re-upload until tomorrow, to give you guys time to look into it. I'm pretty sure deleting the case and re-uploading will solve it.

It could have been possible that it is/was matching from an old case.

Tagging @keyvanelhami as well to keep him in the loop.

[hassanfa]

I don't know how to help, but if you want VCF and config files itself I can share on hasta, etc...

[dnil]

Just knowing that upload happened twice with slightly different data would have me satisfied. If you have both sets of VCFs eg in housekeeper we can check if the variant is indeed differing, and why, but until we know it is not I would sort of feel the issue lies with the pipeline or upload interface. Perhaps we need to make some adjustment to the latter if this was not the intended result? Or perhaps we could add a more informative edit note on variants like these stating that they were no longer found on the case - that may help?

[northwestwitch]

If there is a way to decrypt the MD5 hash that created that variant ID one could check in the VCF for that specific variant..

[dnil]

You probably dont have to decrypt it: you can just look it up in the events table and note the display id for the same event!

[dnil]

(clear text display id should be visible as "subject" on the event).

[northwestwitch]

You probably dont have to decrypt it: you can just look it up in the events table and note the display id for the same event!

🧞‍♂️ !

[northwestwitch]

Found it, in the events

[northwestwitch]

The variant was actually missing from the latest VCF used in the upload, and was present in the previous one. So mystery solved. Closing the issue!

[hassanfa]

👍🏽 this actually helped me think about a way to estimate false discovery rate of Vardict, we'll see. Thanks for the help Scouters!

It wasn't a bug after all, it was a sign!!!!

[dnil]

By the way, if you do find a good attack against the md5 hash, I think you could still make some money on the side with it - it is deprecated since a long time, but even so SHA256 and similar still haven't quite caught on with the whole industry.

[northwestwitch]

I've read about rainbow tables, but I guess this is a bit outside the purpose of Scout..

[dnil]

hehe, yes: that looks fun, but slightly outside scope. As my old pattern recognition research supervisor used to say one should always try to build from domain knowledge. In this case, just enumerating positions of potential interest by say making a table of the variants of interest from the CADD>10 files and hashing those will likely generate a correct match, in contrast to a rainbow string with a match but likely little info given the puny key space.. 😸