Webhooks for firing alerts contain zeroed EndsAt

What did you do?

It appears that webhooks for firing alerts contain zeroed EndsAt timestamps 0001-01-01T00:00:00Z instead of the actual EndsAt timestamp of the alert as can be seen in /v2/alerts.

Having looked into this further the code that causes this can be found on Line 507 of dispatch.go:

for _, alert := range alerts {
	a := *alert
	// Ensure that alerts don't resolve as time move forwards.
	if !a.ResolvedAt(now) {
		a.EndsAt = time.Time{}
	}
	alertsSlice = append(alertsSlice, &a)
}

I think the intention of this code is to prevent alerts from becoming resolved during subsequent stages of the receiver such as WaitStage and DedupStage. This can happen when a firing alert enters the stages at time t1 but doesn't finish the stages until time t2 > EndsAt.

What did you expect to see?

I expect to see either EndsAt contain a non-zero timestamp or for the EndsAt column to be omitted from the JSON for firing alerts.

What did you see instead? Under which circumstances?

Related: https://github.com/prometheus/alertmanager/issues/3341

Start in dispatch/dispatch.go at line 507 and compare the alert's EndsAt there with the value returned by /v2/alerts. Read related issue #3341 to understand the intended handling during later receiver stages, then verify that firing-alert webhooks preserve a meaningful EndsAt or omit the field rather than serializing the zero timestamp.