Repository navigation
fix(messages): extract text from legacy attachments/blocks when content is empty - #18
Open
nulligence wants to merge 1 commit into
Open
nulligence wants to merge 1 commit into
nulligence wants to merge 1 commit into
Conversation
…is empty Bot integrations that post via legacy Slack "attachments" or top-level Block Kit "blocks" (Grafana alerts, threat-investigation bots, etc.) often never populate the plain "text" field. parseRawMessage only ever read raw["text"], so message list/get returned an empty content string for these posts even though the full alert/body was present in attachments[].text/.fallback/.title/.fields or blocks[].text.text — forcing a manual curl fallback against conversations.history to recover the content. Fall back to extracting human-readable text from attachments (including attachments that carry nested Block Kit content instead of legacy fields) and then from top-level blocks, only when "text" is empty, so normal messages are unaffected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
`slack-cli message list`/`message get` return an empty `content`/`text` field for any message whose body lives entirely in a legacy Slack `attachments` block (or top-level Block Kit `blocks`) rather than the plain `text` field. `parseRawMessage` in `internal/slack/messages.go` only ever read `raw["text"]`.
This is common traffic for exactly the channels you'd most want reliable visibility into: Grafana-style alerting bots and other integrations that post via legacy `attachments` (e.g. a "critical-alerts-prod" style channel) consistently came back with a stub or empty body, forcing a manual `curl` against `conversations.history` to recover the actual alert text every time. The same empty-content symptom also showed up on an unrelated bot/integration whose real content lived in `attachments[0].blocks[]` rather than the legacy attachment fields at all, confirming this isn't integration-specific — it's any bot that doesn't populate plain `text`.
Fix
`parseRawMessage` now falls back to extracting human-readable text when `text` is empty:
Messages that already have a plain `text` field are completely unaffected — the fallback only runs when `text` is empty, so normal user/bot messages behave exactly as before.
Added unit tests in `internal/slack/messages_test.go` covering: plain-text messages (unaffected), legacy-attachment-only messages, attachment-with-only-`fallback`, an attachment carrying nested `blocks` instead of legacy fields, and top-level-`blocks`-only messages.
Test plan
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.