[Bug] Prometheus metrics aliasing: multiple unrelated counters share the same value/pointer

Issue Description

In version 0.16.11, the Prometheus metrics exporter (/metrics) assigns multiple different and completely unrelated counter metrics to the same underlying value (likely referencing the same memory address or using an incorrect macro). When one event occurs, all counters in the “aliased” group increment simultaneously.

Expected Behavior

Each Prometheus metric (e.g., server_startup_error, spf_fail, smtp_message_too_large) should maintain its own independent counter and increment only when its specific respective event occurs.

Actual Behavior

Multiple unrelated metric keys point to the exact same value. When only ONE specific event occurs, ALL counters in the aliased group increment simultaneously.

Reproduction Steps

  1. Set up an isolated test environment with no external traffic (only local monitoring and test clients).

  2. Fetch the /metrics endpoint and observe the current values for metrics like delivery_connect, server_startup_error, smtp_message_too_large, and spf_fail (they will all share the exact same number).

  3. Intentionally trigger ONLY ONE specific error (e.g., attempt to send an oversized email from Thunderbird to trigger smtp_message_too_large).

  4. Fetch the /metrics endpoint again.

  5. Observe that ALL unrelated metrics in that group incremented simultaneously by the exact same amount.

Relevant Log Output

BEFORE triggering the error (Notice all values are exactly 11):

delivery_connect 11
delivery_greeting_failed 11
delivery_rcpt_to 11
milter_action_temp_fail 11
resource_error 11
server_startup_error 11
smtp_missing_auth_directory 11
smtp_message_too_large 11
spf_fail 11

AFTER attempting to send one large file (All values jumped to 13 simultaneously):

delivery_connect 13
delivery_greeting_failed 13
delivery_rcpt_to 13
milter_action_temp_fail 13
resource_error 13
server_startup_error 13
smtp_missing_auth_directory 13
smtp_message_too_large 13
spf_fail 13

NOTE: Another group of metrics suffers from the same aliasing issue (sharing the value 17):

smtp_concurrency_limit_exceeded 17
smtp_ehlo_expected 17
smtp_mt_priority_disabled 17
smtp_dsn_disabled 17

Stalwart Version

v0.16.x

Installation Method

Binary (Linux)

Database Backend

RocksDB

Blob Storage

Filesystem

Search Engine

Internal

Directory Backend

Internal

Additional Context

The server is completely isolated from the internet (no background bot traffic).

All incoming emails/connections are generated by Zabbix, a local antivirus, and a test Thunderbird client.

This isolation made it obvious that the metrics are tied together, as it’s impossible to get exactly 11 server startup errors, 11 SPF fails, and 11 oversized emails simultaneously.

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

This has been fixed in v0.16.12 which will be released this week.

Thank you very much!