fix(deps): update github.com/grafana/alerting digest to 5c84f76 (main)

[renovate-sh-app]

This PR contains the following updates:

Package	Type	Update	Change
github.com/grafana/alerting (changelog)	require	digest	d513d62 -> 5c84f76

---

Warning

Some dependencies could not be looked up. Check the warning logs for more information.

---

Configuration

📅 Schedule: Branch creation - Between 12:00 AM and 04:59 AM, only on Monday ( * 0-4 * * 1 ) (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

Need help?

You can ask for more help in the following Slack channel: #proj-renovate-self-hosted. In that channel you can also find ADR and FAQ docs in the Resources section.

[CLAassistant]

All committers have signed the CLA.

[renovate-sh-app]

ℹ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

• 3 additional dependencies were updated

Details:

Package	Change
github.com/prometheus/alertmanager	v0.28.1 -> v0.28.2
github.com/at-wat/mqtt-go	v0.19.4 -> v0.19.6
github.com/go-openapi/runtime	v0.27.1 -> v0.28.0

[cursor]

Bug: Flawed Renaming Logic Causes Conflict Errors

In MergeReceivers, after renaming a receiver, the code sets usedNames[cpy.Name] = i but i refers to the index of the conflicting item that triggered the rename, not the current item's index. This should be usedNames[cpy.Name] = idx to correctly track which incoming receiver now has this name. This can cause incorrect conflict detection for subsequent receivers with the same name, potentially leading to missed renames or incorrect renaming behavior when multiple incoming receivers share the same original name.

 

[cursor]

Bug: MergeTimeIntervals loses incoming mute time intervals

The MergeTimeIntervals function signature was changed to return only ([]config.TimeInterval, map[string]string) instead of ([]config.MuteTimeInterval, []config.TimeInterval, map[string]string). However, the result now uses a.MuteTimeIntervals directly instead of the merged mute time intervals. This causes incoming mute time intervals from configuration b to be silently dropped during the merge, breaking alert routing configurations that depend on mute time intervals from the secondary configuration.

Additional Locations (1)

• vendor/github.com/grafana/alerting/definition/merge.go#L146-L153

 

[cursor]

Bug: CSV unmarshal panics when destination slice has existing elements

The refactored CSV unmarshaling code calls v.SetCap(len(csvWriter.records)) before resetting the slice length. According to Go's reflect documentation, SetCap panics if n is smaller than the current length of the slice. If a caller passes a destination slice that already contains more elements than the incoming CSV records, this will panic. The previous implementation correctly handled this by calling v.SetLen(0) first, then using AppendSlice to populate the data. This is a regression that could cause runtime panics in edge cases where pre-populated slices are reused.

 

[cursor]

Bug: Missing nil check causes potential panic in receivers merge

The new createIndexReceivers function accesses .Name on receivers without checking if they're nil. Both loops iterate over existing and incoming slices of pointers, but unlike the calling function MergeReceivers which checks if r == nil, this helper function directly accesses e.Name (line 356) and i.Name (line 359-360). If either slice contains a nil entry, this causes a nil pointer dereference panic.

 

[cursor]

Bug: InitSchema returns struct with dangling pointer references

The InitSchema function receives the schema by value, sets typeSchema pointers on each version to point to the local variable &s, then returns s by value. After the function returns, the typeSchema pointers in the returned struct's Versions still reference the function's stack-local copy of s, which becomes invalid memory. Any subsequent call to GetTypeSchema() or Type() on a version will dereference a dangling pointer, causing undefined behavior or crashes.

 

[cursor]

Bug: Test notifications use integration type instead of receiver name

The TestNotifier function sets context values using notifier.Name(), which returns the integration type (e.g., "slack", "email") rather than the receiver's configured name. The previous implementation used next.ReceiverName from the job struct, which contained the actual receiver name. This causes the group key format and receiver name in context to differ from before, affecting notification history recording which will now show integration types instead of meaningful receiver names. The function lacks a receiverName parameter to preserve the original behavior.

 

[cursor]

Bug: Reflection panic on nil pointer in slice elements

In ConfigReceiverToMimirIntegrations, when processing slices of pointer types (e.g., []*EmailConfig), the code calls item.Elem().Interface() without checking if item represents a nil pointer. If a slice contains a nil element, item.Elem() returns an invalid reflect.Value, and calling Interface() on it will panic with "reflect: call of reflect.Value.Interface on zero Value".