Error caused by allele_qc when modifying annotations

[jseager7]

Some time ago, our curators noticed a strange error that showed up every time a user attempted to Edit, Copy and Edit, or Transfer a genotype or metagenotype annotation.

The error appeared as a toaster notification stating 'unsupported range part: /allele_qc/check_modification'.

The error also stopped Canto from starting, as shown in the service log:

Started LSB: Canto community annotation tool.
Canto loading ...
unsupported range part: /allele_qc/check_modification
Compilation failed in require at /canto/./script/canto_start line 82.

If I remember correctly, I fixed the problem by updating Canto's Docker image, which might have happened automatically after updating Canto's source code.

The concerning thing about the error was that it seemed like it happened without any obvious changes on our side, as if an update to the Docker image had somehow broken our code without warning. I was hoping that not doing git pull would be enough to shield us from potentially breaking changes by PomBase, but perhaps this isn't the case?

@kimrutherford Do you have any insight on what happened here?

[jseager7]

This error might be related to issue https://github.com/pombase/canto/issues/2688.

[ValWood]

Hi @jseager7 just so you know, Kim is on holiday this week, so he most likely wont respond until next week .

[kimrutherford]

Hi James. Sorry about that. I didn't think through how this change would affect you.

This error might be related to issue https://github.com/pombase/canto/issues/2688.

Yep.

I added a unpleasant hack in order to implement (part of) that issue.

After that change, we now have a new range type in the extension configuration to allow checking of residue range values using an external service (implemented by @manulera). For now we're just checking the residues specified in modification extensions to make sure that the value matches the protein sequence. So for example, if the user enters "T12" we check that there really is a "T" at residue 12. This will prevent a lot of errors accumulating in our data.

The concerning thing about the error was that it seemed like it happened without any obvious changes on our side, as if an update to the Docker image had somehow broken our code without warning.

Is it possible you updated the extension configuration but not the Canto code? There was a config change and a matching code change.

I'm guessing that the problem you're seeing is caused by this line in PSI-MOD_A_E_config:

MOD:00000    is_a    residue   /allele_qc/check_modification    position modified, e.g. K23    0,1    user

The /allele_qc/check_modification is the API endpoint that does the checking.

I forgot PHI-Canto has modification annotations configured and that this change could cause problems for you. I think the solution for PHI-Canto is to have your own copy of PSI-MOD_A_E_config and remove that line. Sorry that's not great.

[jseager7]

Is it possible you updated the extension configuration but not the Canto code? There was a config change and a matching code change.

I think this is probably the reason.

I added a script a while ago to automatically synchronise our annotation extension configuration with the files stored at pombase/pombase-config before the nightly ontology reload, and that must've allowed the change to be applied without me having any chance of seeing it.

I assumed at the time that the annotation extension configuration couldn't cause Canto to not start, but since that's not guaranteed, I might have to go back to semi-automatic deployment for these files.

Alternatively, I could remember to update Canto's source code more often… 😓

[ValWood]

Is this still an issue?

[jseager7]

I'll close this since we found the reason for the error. The solution is probably for me to be more careful when updating Canto.