Erik Miller
f399a7acab
When a Backstage notification is re-sent with the same scope, the notifications backend updates the existing DB record and sets notification.updated. Previously, the SlackNotificationProcessor always called chat.postMessage(), creating duplicate Slack messages. This adds database-backed scope-based update support: - New slack_message_timestamps table to persist Slack message ts values keyed by (scope, channel) - After each chat.postMessage(), store the response ts in the database - When postProcess receives a notification with updated set and a matching stored ts, use chat.update() instead of chat.postMessage() - Scope context is passed as parameters through the call chain to avoid race conditions with concurrent postProcess calls - Scheduled daily cleanup of old timestamp records (24h retention) - New messagesUpdated metrics counter for observability - Graceful degradation when no database is provided - Explicitly picks only supported fields for chat.update calls Signed-off-by: Erik Miller <erik.miller@gusto.com>
531 B
531 B
@backstage/plugin-notifications-backend-module-slack
| @backstage/plugin-notifications-backend-module-slack |
|---|
| patch |
Added scope-based message update support. When a notification is re-sent with the same scope and notification.updated is set, the processor now calls chat.update() on the existing Slack message instead of sending a duplicate via chat.postMessage(). Message timestamps are persisted in a new slack_message_timestamps database table with automatic daily cleanup. The processor gracefully degrades to the previous behavior when no database is provided.