Alerting after the Task System Redesign: silent task transitions, unreachable alert configurations, unscoped thread delivery

[manerow]

Scope

The Task System Redesign (#25894) promoted Task and Announcement to first-class entities and left
Conversation as a Thread sub-type, but did not revisit the alerting layer. This epic tracks the
consequences, which fall into three families. Design blueprint:
ALERTING_AFTER_TASK_REDESIGN.md.

1. Alerts deliver the wrong things

• Entity-scoped alert filters are bypassed for thread events (alerts deliver conversations outside their scope) #30555 - entity-scoped filters (FQN, owner, domain, entity id, source) are bypassed for thread events, so an alert scoped to one entity receives conversations about all of them. Fixed by fix(alerts): scope thread events by their parent entity instead of bypassing filters #30571. (Thread events reaching entity resources at all is what fix(alerts): thread events now trigger entity-scoped notification alerts #28122 and fix(alerts): observability status triggers no longer fire on thread events #29112 shipped in 1.12.9 and 1.13; this is the consequence that surfaced.)

2. Task lifecycle transitions are invisible or misdescribed

• Task lifecycle change events are emitted only from the HTTP resource layer (internal, workflow and bulk transitions stay silent) #29038 - change events are emitted only from the HTTP resource layer, so bulk, incident-driven and workflow-driven transitions stay silent, and there is no /reopen endpoint at all.
• Task resolve/close change events carry a stale changeDescription (status and resolution absent) #30556 - the resolve/close event that does fire carries a stale changeDescription naming workflow-stage fields instead of status and resolution.
• Bulk task endpoint emits no per-task change events (subsumed by #29038) #29041 - the bulk endpoint emits nothing. Closed, subsumed by Task lifecycle change events are emitted only from the HTTP resource layer (internal, workflow and bulk transitions stay silent) #29038, whose handler-layer fix covers it; its test criteria moved there.

3. The vocabulary and the descriptors advertise what the backend cannot honor

• Declare supportedEventTypes per alert resource and reject unreachable event types at save time #30557 - nothing declares which event types a resource can emit, and the API validates filter names but never their values.
• Alert builder offers every EventType regardless of the selected resource (UI half) #29040 - the alert builder populates the event-type list from the whole enum regardless of resource.
• Retire orphan EventType values: taskCreated, taskUpdated and the five suggestion* values #29039 - orphan EventType values (taskCreated, taskUpdated, and the five suggestion* values), plus the 1.13 -> 2.0 migration matrix for stored subscriptions.
• task and announcement alert resources expose almost no filters #30558 - task exposes only filterByMentionedName and announcement exposes no filters at all.
• Retire the legacy thread-task alerting surface once the Recognizer Feedback workflow is migrated #30559 - the legacy thread-task alerting surface, blocked on migrating the Recognizer Feedback workflow.

Release scope: TaskResource and entity/tasks/task.json do not exist on 1.13, so every Task-entity
facet above is main / 2.0 only. The resource-gate fix (#28122) and its observability guard (#29112)
did reach 1.12.9 and 1.13.

A status pass re-verified against main on 2026-07-28 is in
this comment.

---

Origin

Reported by a customer in May 2026: a Notification alert on glossaryTerm filtering on
Thread Created / Thread Updated never fired, with zero entries in Recent Events and no error
anywhere. That specific case was fixed by #28122 and shipped in 1.12.9 and 1.13. Investigating it
surfaced the rest of the drift tracked above.

Internal discussion: https://collate-inc.slack.com/archives/C096NDJQAJW/p1777900803665159