Prometheus counters are off if a transaction is rolled back.

[SemMulder]

Prometheus counters are off if a transaction is rolled back, because we mutate the counters within the transaction. See #132 (comment). Perhaps we should only mutate counters after the transaction is comitted?

[jerbaroo]

Perhaps we should only mutate counters after the transaction is comitted?

So there would still be a chance of the counter being off, but only if there is a crash between the transaction and the counter update. Seems less likely to occur than a rollback? Solution sounds good to me. Changes the semantics of the counter from a possible upper bound to lower bound.

[SemMulder]

Seems less likely to occur than a rollback?

This precisely :).

Going beyond that will start becoming really hard (CAP-theorem and all that jazz).

[SemMulder]

The tricky thing will be the plumbing in deferring the counter changes to after the COMMIT.

To that end, defer-rs might be interesting. It allows a customized scope to be specified at which the deferred statements should be run: https://docs.rs/defer-rs/latest/defer_rs/. It wouldn't work, doesn't allow crossing function boundaries.

[SemMulder]

Maybe we could pass an on_commit: &mut Vec<Box<dyn FnMut()>> to the inner function in Connection::transaction.