Reason:
If we query a new variant by GET, then it calls my variant info GET endpoint, and cache annotation to database.
Response format:
If we query a new variant by POST, then it calls my variant info POST endpoint, and cache annotation to database.
Response format:
GET response doesn't have query field but we need it as the key to mapping hgvsg with my_variant_info annotation. So if one variant is queried by GET for the first time, it won't have query in the cache, so it won't be able to be found by POST requests later on.
Fix:
Always use POST to get my variant info so new annotation could have query field. Clean up database to remove my variant info annotation cache that has no query field(those variants will be re-cached when they are queried later).
Todo:
[x] Always use POST to get my variant info, because GET response doesn't have query field but we need it as the id to mapping hgvsg with my_variant_info annotation
[x] Clean up database to remove my variant info annotation cache that has no query field
https://www.signaldb.org/variant/17:g.41276045_41276046del https://www.signaldb.org/gene/BRCA1 look for E23Vfs*17
Reason: If we query a new variant by GET, then it calls my variant info GET endpoint, and cache annotation to database. Response format:
If we query a new variant by POST, then it calls my variant info POST endpoint, and cache annotation to database. Response format:
GET response doesn't have
queryfield but we need it as the key to mapping hgvsg with my_variant_info annotation. So if one variant is queried by GET for the first time, it won't havequeryin the cache, so it won't be able to be found by POST requests later on.Fix: Always use POST to get my variant info so new annotation could have
queryfield. Clean up database to remove my variant info annotation cache that has noqueryfield(those variants will be re-cached when they are queried later).Todo:
queryfield but we need it as the id to mapping hgvsg with my_variant_info annotationqueryfield