argoproj / argoproj/notifications-engine

Support Slack message updates and replies by ts

Open
#187 5 comments 1 reaction 0 assignees View on GitHub
Dominant language
Go
Stars
334
Forks
217
PR merge metrics
No merged PRs in 30d

Description

It would be useful for the Slack integration to directly support

* the [`thread_ts` option](https://api.slack.com/methods/chat.postMessage#arg_thread_ts) when posting a message, and
* the [`ts` argument](https://api.slack.com/methods/chat.update#arg_ts) for updating a message.

This would allow notifications to reply to specific threads and update specific messages.

For example, supplying `slack.thread_ts` would respond to the Slack message by including it in the payload of [chat.postMessage](https://api.slack.com/methods/chat.postMessage):
```yaml
template.app-sync-status: |
message: |
This is a reply to a thread
slack:
threadTs: "12345678.1234567"
```

And supplying `slack.update_ts` would update a Slack message by instigating a [chat.update](https://api.slack.com/methods/chat.update) request and including its value in the `ts` option:
```yaml
template.app-sync-status: |
message: |
This is an updated message
slack:
updateTs: "12345678.1234567"
```

`threadTs` and `updateTs` would both be optional, and mutually exclusive.
`threadTs` and the existing `groupingKey` would be mutually exclusive.

Non-BC-breaking.

I am not familiar with Go so I probably won't be able to implement this myself, but I'm hoping this enhancement gets support from contributors.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start at the Slack integration's handling of chat.postMessage and the existing groupingKey behavior, then compare the request shapes with Slack's thread_ts and ts arguments. Confirm how configuration maps camelCase fields such as threadTs and updateTs. Done means optional thread replies and message updates work, the stated mutual exclusions are enforced, and existing grouping behavior remains unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
backend
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.