fix: Propagate muted flag to :error telemetry events

[reciproco]

Hi @crbelaus,

We're a team that has been using your library in production for a few months now, and we're very happy with it. Thank you very much for your work.

We ran into a situation where the mute action exposed in the dashboard wasn't being respected by our notifier. Our handler subscribes to [:error_tracker, :error, :new] and [:error_tracker, :error, :unresolved] and inspects metadata.error.muted before sending an alert, so muted errors should silently pass through. In practice it never did: every dispatched %Error{} struct carried muted: false, regardless of the row's real state in the DB, so errors that operators had explicitly silenced from the UI kept paging us.

The [:error_tracker, :occurrence, :new] event does expose a working :muted metadata key, but it isn't the right signal for our use case — we only want to react to genuinely new errors and to regressions (resolved → unresolved), not to every individual occurrence.

After digging in we found that upsert_error!/5 already reads both existing_status and muted from the DB before the upsert, but it never stamps muted onto the in-memory struct it hands to Telemetry.new_error/1 /Telemetry.unresolved_error/1. Because Repo.insert!(_, on_conflict: [set: [...]]) doesn't round-trip the columns it didn't set, the struct keeps the schema default (muted: false) even when the DB row is muted.

We've been running a fork with this fix for a while and it's worked well for us. We wanted to offer it upstream in case you find the direction acceptable. We're happy to adjust the approach if you'd prefer a different shape or semantics — please consider this a humble proposal rather than a prescription.

Changes

• Stamp the in-memory Error struct with the muted value already fetched from the DB, right before dispatching the :new and :unresolved telemetry events.
• No public API change: the Error schema already declares muted, so existing subscribers that read metadata.error.muted start receiving the real value without any code change on their side.
• The [:error_tracker, :occurrence, :new] event is untouched (it already exposes :muted as a separate metadata key, and that path was working correctly).

Why this shape, and not a separate metadata key

The Error schema already declares muted as a field, so the struct felt like the natural place for that information to live. Updating the struct keeps consistency with how the rest of the code treats %Error{} and avoids changing the metadata shape on existing subscribers. That said, if you'd rather expose :muted as a separate metadata key on the :new / :unresolved events to mirror :occurrence, :new, we're happy to switch to that.

Test plan

• New regression test added in test/error_tracker/telemetry_test.exs that mutes and resolves an error, triggers it again, and asserts the :unresolved payload reflects muted: true.
• Confirmed the test fails on main (the dispatched struct shows muted: nil) and passes with the fix applied.
• Full suite passes with --warnings-as-errors.

Regards

[crbelaus]

This is looking great. Thanks for your contribution! 🙇