Closed Peter-J-Freeman closed 1 month ago
Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
Can we set up some kind of system that notifies me when warnings or error messages change? Or, is there some kind of index or dictionary where I can see what possible warnings or error messages can be created by VV? Since there are no error codes, LOVD parses the strings sent by VV to try and figure out what is information, a warning, or an error. When the strings change, LOVD doesn't know what the message means anymore since it doesn't match any of the pre-configured strings. I noticed yesterday during the VIJ meeting (after we discussed providing feedback about the availability of new transcript versions) that my tool now considers using an older transcript version as a fatal error because the string changed somewhere along the way. I sometimes add new strings when I notice a new message I don't match yet, although this probably also means some other message can be removed. However, I don't have an overview of when things change or what possible errors exist. Of course, having permanent error codes would be even better, but as an alternative, can we set up some system that notifies me so I can adapt the LOVD-VV library in time?
We definately need some discussion around this. Some serious issues have arisen since we migrated to the Ensembl data.
I think ErrorCodes are the way to go. We did start including these. In this case we could add the prefix TranscriptVersionError: (or warning perhaps TranscriptVersionWarning: )
We need to go through the code base and add error prefixes to all error messages and document them. This is a big job, but I should get on with it over the summer!!!!
Note, this error message will stay. Do you want me to add the prefix and push a new version @ifokkema. If so, what prefix?
Have added in the flag TranscriptVersionWarning: as the error code here
I think ErrorCodes are the way to go. We did start including these.
That would be awesome!
In this case we could add the prefix TranscriptVersionError: (or warning perhaps TranscriptVersionWarning: )
Sounds good! FYI: Within LOVD, there are three levels of provided output, prefixed with I, W, or E, respectively:
delA
instead of del
, and 3' shifting also fit in this category.I copied the design of the codes, words in capitals without spaces prefixed with a single letter indicating the type of message from Mutalyzer2. There is, obviously, no need to copy this design, as long as LOVD can understand what's an information message, what's a warning, and what's an error. Also, LOVD can perhaps consider some things just information what you consider a warning, etc. That's all cool, as long as LOVD knows what you mean, so I can create a mapping. I will try to support all your codes, which will be easier if we'll create a document somewhere containing all possible messages. We could even document, if you'd like, what LOVD will make of it and possibly additional messages that LOVD generates (e.g., LOVD generates WROLLFORWARD: Variant positions have been corrected. when the VV output indicates the variant has been shifted 3'. This may also help the implementation of LOVD's checkHGVS API into VV.
Note also that, within LOVD, the information, warning, and error lists are objects, and the codes are the keys. So the users don't see the codes, they are for internal use. Also, somebody could do a count of warnings to quickly check how many warnings are returned, or do a check for a non-zero count of the errors key. LOVD returns, e.g.,:
{
"NM_002225.3:c.157C>T": {
"messages": {
"IOK": "This variant description is HGVS-compliant."
},
"warnings": [],
"errors": [],
"data": {
"position_start": 157,
"position_end": 157,
"type": "subst",
"range": false,
"suggested_correction": []
}
}
}
This is just FYI, in case you like the idea, you could use it in later versions of APIs.
We need to go through the code base and add error prefixes to all error messages and document them. This is a big job, but I should get on with it over the summer!!!!
I can imagine! Something that I should have done in the past and might be useful, is to document a variant description with each message/warning/error so that you can easily trigger it to have a look. I failed to do that, and now I don't know how to purposefully trigger certain errors in VV.
Note, this error message will stay. Do you want me to add the prefix and push a new version @ifokkema. If so, what prefix?
No rush, no worries! I'll just wait for the full update that will include error codes for everything. I'll fix the issue with the transcript version being considered fatal independently.
Opened an issue @ifokkema
…lignments available