Ah, okay, got it, it's probably getting 4 by actually counting the alleles as observed in GT, overriding the values in the INFO field, which in my example contradict the genotypes. So it wasn't a very good example. However, now consider this case:

Test data

Those are two summary VCFs without genotypes (permitted by the spec).

tr '|' '\t' << EOF | bgzip > C.vcf.gz
##fileformat=VCFv4.3
##INFO=<ID=AN,Number=1,Type=Integer,Description="Some metric">
#CHROM|POS|ID|REF|ALT|QUAL|FILTER|INFO
chr1|123|.|A|C|.|.|AN=30
EOF

tr '|' '\t' << EOF | bgzip > D.vcf.gz
##fileformat=VCFv4.3
##INFO=<ID=AN,Number=1,Type=Integer,Description="Some metric">
#CHROM|POS|ID|REF|ALT|QUAL|FILTER|INFO
chr1|123|.|A|C|.|.|AN=12
EOF

parallel tabix ::: *.vcf.gz

Merge

./bcftools merge --info-rules 'AN:sum' C.vcf.gz D.vcf.gz

Output

##fileformat=VCFv4.3
##FILTER=<ID=PASS,Description="All filters passed">
##INFO=<ID=AN,Number=1,Type=Integer,Description="Some metric">
##contig=<ID=chr1>
##bcftools_mergeVersion=1.11+htslib-1.11
##bcftools_mergeCommand=merge --info-rules AN:sum C.vcf.gz D.vcf.gz; Date=Tue Feb  2 16:22:01 2021
#CHROM	POS	ID	REF	ALT	QUAL	FILTER	INFO
chr1	123	.	A	C	.	.	.

Notice how this drops the AN field entirely. Is this intended behaviour?

Yes, this is deliberate, as AC and AN are computed from the sample genotypes. Is there a strong motivation for keeping them?

Sorry, pressed the wrong button.

I will mark this as a feature request: in case merge rules are given explicitly for AN, the program could use that instead of its default behavior

Hi Petr! Sorry I didn't get back to you back in February.

To give some context (better late than never), this report arose from the CINECA project. The workflow we were using went like this:

1. On a bunch of samples within controlled-access human cohorts, compile some summary VCFs which contain no genotypes (for privacy reasons), but do contain summary metrics like AC, AN, and others.
2. Collect summary VCFs and merge them into a meta-summary VCF, combining the fields using certain rules.

In CINECA we managed to get around this by temporarily renaming the fields, so it's definitely not urgent or anything. Treating this as a low priority feature request seems to be the most sensible option to me.

I am running into the same issue when merging gnomAD exomes and genomes VCFs which do not contain sample information. Our use case is to create a single VCF containing the summed AC and AN. I came up with the same merge command as the author of this issue which didn't give the expected result.

@pd3 an alternative to the feature request you mention could be to change the default behavior in case of no available samples such that /bcftools merge --info-rules 'AN:sum' C.vcf.gz D.vcf.gz would give the same result as ./bcftools merge C.vcf.gz D.vcf.gz. what do you think?

This is now supported. When no genotypes are present, AC,AN will be summed. When they are present, the values will be recalculated unless -i AC:sum,AN:sum is given, in that case they will be summed as well.