Another snpEff regression between versions 5.0 and 5.1/5.2

[tillea]

Describe the bug
This issue is a followup to issue #455 which was luckily solved by a hint from /cc: @pcingola . I've fixed the snpEff build call in snippy by a patch which worked nicely to continue the test suite
Unfortunately it now fails in a some snpEff ann call.

To Reproduce

1. SnpEff version: 5.2b
2. Download and unzip this example data set
   example2.zip
3. cd example
4. snpEff ann -noLog -noStats -no-downstream -no-upstream -no-utr -c reference/snpeff.config -dataDir . ref snps.filt.vcf > snps.vcf

$ head -n3 snps.vcf 
 ann -noLog -noStats -no-downstream -no-upstream -no-utr -c reference/snpeff.config -dataDir . ref snps.filt.vcf
##fileformat=VCFv4.2
##FILTER=<ID=PASS,Description="All filters passed">

6. The first line is making he result file an illegal format

The next step of snippy is

$ bcftools convert -Oz -o snps.vcf.gz snps.vcf
Failed to open snps.vcf: unknown file type

which fails. If I remove the first line of snps.vcf bcftools works smoothly.

Expected behavior
The result should not contain the first line which is repeating the call

Data
See above.

Remark
May be snippy is just wrongly implementing snpEff features but it is know to work with snpEff 5.0.

Kind regards, Andreas.

[pcingola]

I'm not sure how the first line is being corrupted by SnpEff, to me it looks like it's comming from your original file:

Let's compare the head of each file

$ head -n3 snps.filt.vcf > head.ori
$ head -n3 snps.filt.vcf > head.snpeff

# Diff has no output
$ diff head.ori head.snpeff
$

Let's try an md5 checksum:

$ md5 head.ori head.snpeff
MD5 (head.ori) = e52fffc5f09e0fd8b5682e9040201635
MD5 (head.snpeff) = e52fffc5f09e0fd8b5682e9040201635

They look identical to me.

I'm not sure if I'm missing your point, but it looks like SnpEff is just copying the header from the original file and the problem resides in the original file.

[pcingola]

Closing for the moment as it looks not a SnpEff problem. Feel free to re-open.