Currently, PrometheusRemoteWriteProvider, unlike the rest of our charms, does not send any events at all when the status changes.
It seems that the Prometheus charm listens/listened directly to events from that interface, and called a "common exit hook" which masked the issue by always re-reading alerts on every event.
Solution
Send events which can be watched, so charms and libraries keep their appropriate scope of responsibility. Otherwise, this library behaves differently from all of our others, and it's easy to "lose" or "drop" data.
Deploy, listen to events, make sure things fire. Unit tests and integration tests were not changed, as "remove the raw listeners and they pass with the other event" is a reasonable assurance that this change did not break code/functionality.
Authors/users who were previously directly monitoring the relation still can, but now they don't have to.
Issue
Currently,
PrometheusRemoteWriteProvider, unlike the rest of our charms, does not send any events at all when the status changes.It seems that the Prometheus charm listens/listened directly to events from that interface, and called a "common exit hook" which masked the issue by always re-reading alerts on every event.
Solution
Send events which can be watched, so charms and libraries keep their appropriate scope of responsibility. Otherwise, this library behaves differently from all of our others, and it's easy to "lose" or "drop" data.
Context
See the comments for Mimir here.
Testing Instructions
Deploy, listen to events, make sure things fire. Unit tests and integration tests were not changed, as "remove the raw listeners and they pass with the other event" is a reasonable assurance that this change did not break code/functionality.
Authors/users who were previously directly monitoring the relation still can, but now they don't have to.
Release Notes
Send events from
PrometheusRemoteWriteProvider