Unexpected return code of 0 while erroring

[wdecoster]

Hi,

I noticed superstr unexpectedly returned a returncode of 0, while it ran into an error. I was running this on a cram file, for which it seems I do not have the correct permissions to the reference files.

stderr contained:

[W::find_file_url] Failed to open reference "http://www.ebi.ac.uk/ena/cram/md5/2648ae1bacce4ec4b6cf337dcae37816": Destination address required
[E::fai_build3_core] Failed to open the file /research/bsi/archive/cram_references/GRCh38/GCA_000001405.15_GRCh38_no_alt_short_headers_nonACTG_to_N.fa
[E::refs_load_fai] Failed to open reference file '/research/bsi/archive/cram_references/GRCh38/GCA_000001405.15_GRCh38_no_alt_short_headers_nonACTG_to_N.fa'
[E::cram_get_ref] Failed to populate reference for id 0
[E::cram_decode_slice] Unable to fetch reference #0:9999-29187

[E::cram_next_slice] Failure to decode slice

stdout contained:

Successful run; processed 0 reads.

I have a different idea of 'successful' ;-) It makes me a bit worried about having to search for errors.

Best,
Wouter

[lfearnley]

Hi Wouter, Thanks for the bug report. We assumed you'd be processing data that you had permissions to, so I can see why this isn't a great message. To confirm - when you fix the permissions on the reference (or build the ref cache locally), it runs ok? That ENA URL is giving me a 404 at the moment.

…

On Mon, 13 Nov 2023, 8:04 pm Wouter De Coster, ***@***.***> wrote: Hi, I noticed superstr unexpectedly returned a returncode of 0, while it ran into an error. I was running this on a cram file, for which it seems I do not have the correct permissions to the reference files. stderr contained: [W::find_file_url] Failed to open reference " http://www.ebi.ac.uk/ena/cram/md5/2648ae1bacce4ec4b6cf337dcae37816": Destination address required [E::fai_build3_core] Failed to open the file /research/bsi/archive/cram_references/GRCh38/GCA_000001405.15_GRCh38_no_alt_short_headers_nonACTG_to_N.fa [E::refs_load_fai] Failed to open reference file '/research/bsi/archive/cram_references/GRCh38/GCA_000001405.15_GRCh38_no_alt_short_headers_nonACTG_to_N.fa' [E::cram_get_ref] Failed to populate reference for id 0 [E::cram_decode_slice] Unable to fetch reference #0:9999-29187 [E::cram_next_slice] Failure to decode slice stdout contained: Successful run; processed 0 reads. I have a different idea of 'successful' ;-) It makes me a bit worried about having to search for errors. Best, Wouter — Reply to this email directly, view it on GitHub <#22>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC25LCK7ELUCBDQDP5RBN4DYEHPDHAVCNFSM6AAAAAA7IZZ4JOVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE4TAMJYHEZDOMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[wdecoster]

We assumed you'd be processing data that you had permissions to, so I can see why this isn't a great message.

Oh yeah, fair assumption, but shit happens :)

I already contacted the sysadmin to look into the permissions, as building the ref cache locally led to an error where the reference I downloaded differed from the one that was used for generating the crams - a bit of a mess!

Wouter

[lfearnley]

That's very odd. I'm wondering if the root cause is somehow linked to that contig's MD5 not being in the ENA? I'll patch that message to be more clear later this week - I'm just wondering if there's something else happening here.

…

On Mon, 13 Nov 2023, 9:08 pm Wouter De Coster, ***@***.***> wrote: We assumed you'd be processing data that you had permissions to, so I can see why this isn't a great message. Oh yeah, fair assumption, but shit happens :) I already contacted the sysadmin to look into the permissions, as building the ref cache locally led to an error where the reference I downloaded differed from the one that was used for generating the crams - a bit of a mess! Wouter — Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC25LCNBIKD53U5I7J6TGOTYEHWQ5AVCNFSM6AAAAAA7IZZ4JOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBXHA2DOMRZHA> . You are receiving this because you commented.Message ID: ***@***.***>

[wdecoster]

Alright - I will let you know if I figure out more. But would there be any reason that processing 0 reads could be considered good? Maybe that on its own is enough to fail. I don't know if you can escalate the htslib error, or if it is a samtools call raise the (presumably non-zero) return code?