fix: prevent Slack message loss when response exceeds 3000-char block limit#37
Closed
electronicBlacksmith wants to merge 5 commits intoghostwright:mainfrom
Closed
Conversation
Messages with file attachments (subtype: file_share) were silently dropped by the blanket subtype filter. This downloads attached images to data/uploads/ and appends file paths to the prompt so the agent can read them via its Read tool. Also adds files:read to the Slack app manifest.
The downloadSlackFiles() function used unsanitized Slack filenames directly in join(), allowing crafted names with ../ to write outside the uploads directory. Also, url_private was fetched without hostname validation, enabling SSRF via crafted file records. Fixes: - Extract file handling into slack-files.ts with sanitizeFilename() that strips directory components and null bytes, plus defense-in-depth resolve().startsWith() check (matching isPathSafe in ui/serve.ts) - Add SSRF host allowlist restricting downloads to files.slack.com and files-pri.slack.com - Add Zod schema validation for Slack file records (external input) - Store botToken as private field instead of fragile double-cast through this.app.client 30 new tests covering sanitization, Zod rejection paths, SSRF blocking, download failures, and cleanup lifecycle.
When users attach non-image files (PDF, CSV, etc.) to Slack messages, the files were silently dropped with no indication. Users had no way to know their attachment was ignored. - Add SkippedFileInfo type with structured reasons (unsupported_type, too_large, download_failed) and optional mimetype - Widen InboundAttachment to discriminated union (image | document) for future file type support - Wire skippedFiles through both app_mention and DM event handlers - Append skipped file context to agent prompt so it can naturally inform the user about unsupported attachments - Update slack.test.ts to verify skippedFiles on skip and failure
Bun's mock.module replaces modules process-wide, causing other test files (config, evolution, roles) to lose real fs functions like writeFileSync and mkdirSync. This caused 114 test failures in CI. Replace node:fs mocking with real temp directories for cleanup tests and remove fs-dependent integration tests that are now covered by the unit tests in slack-files.test.ts.
… limit Phantom's final Slack message was silently dropped when the response exceeded Slack's per-section mrkdwn block limit of 3000 characters. The old code used a 3900-char cap in truncateForSlack and splitMessage, which is above Slack's actual limit. Any response between 3000 and 3900 chars would cause the chat.update API call to fail with invalid_blocks, and the user would never see the message. Worst kind of failure: no error surfaced anywhere. Root cause: the 3900 constant in slack-formatter predated the current Slack block-kit constraint (3000 per section text). Blocks are stricter than the older top-level text field. Fix: - Introduce SLACK_BLOCK_TEXT_MAX = 2900 in slack-formatter (100 chars of headroom for the Response truncated notice suffix, which is ~57 chars). - truncateForSlack and splitMessage now default to SLACK_BLOCK_TEXT_MAX so every chunk fits comfortably inside a single section block. - updateWithFeedback in slack.ts now handles multi-chunk responses: edits the first chunk into the existing placeholder message, posts the rest as threaded replies, and attaches feedback buttons only to the final chunk so the rate-this-response affordance is not duplicated. - index.ts passes the thread timestamp to updateWithFeedback at both call sites (progress-stream path and fallback path) so the multi-chunk replies thread correctly. Tests: - New 28k-char response splits into chunks test uses realistic paragraph content and verifies word-by-word preservation across chunk boundaries. - Existing truncates a large response test now asserts result.length < 3000 (the actual API constraint) instead of tracking the buggy 3900 value. - Renamed the default-limit test to track SLACK_BLOCK_TEXT_MAX so future changes to the constant propagate into test assertions automatically. Pre-existing note not fixed here: src/channels/slack.ts is 479 lines, over the 250-line guidance in CONTRIBUTING.md. This PR adds 35 lines to that file; splitting it is a separate refactor that would dilute the focus of this fix.
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
1 participant
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.
Summary
Phantom's final Slack message is silently dropped when the response exceeds Slack's per-section mrkdwn block limit of 3000 characters. The old code used a 3900-char cap in
truncateForSlackandsplitMessage, which is above Slack's actual limit. Any response between 3000 and 3900 chars causes thechat.updateAPI call to fail withinvalid_blocks, and the user never sees the message. No error surfaced anywhere — the worst kind of failure.Root cause
The 3900 constant predated the current Slack block-kit constraint (3000 per section text). Blocks are stricter than the older top-level
textfield, and the formatter was still targeting the old limit.Fix
SLACK_BLOCK_TEXT_MAX = 2900inslack-formatter(100 chars of headroom for the ~57-char truncation notice suffix).truncateForSlackandsplitMessagenow default toSLACK_BLOCK_TEXT_MAXso every chunk fits comfortably inside a single section block.updateWithFeedbackinslack.tsnow handles multi-chunk responses: edits the first chunk into the existing placeholder message, posts the rest as threaded replies, and attaches feedback buttons only to the final chunk so the rate-this-response affordance is not duplicated.index.tspasses the thread timestamp toupdateWithFeedbackat both call sites (progress-stream path and fallback path) so multi-chunk replies thread correctly.Tests
result.length < 3000(the actual API constraint) instead of tracking the buggy 3900 value.SLACK_BLOCK_TEXT_MAXso future changes to the constant propagate into test assertions automatically.Pre-existing issue (not fixed here)
src/channels/slack.tsis 479 lines, over the 250-line guidance in CONTRIBUTING.md. This PR adds 35 lines to that file. Splittingslack.tsis a separate refactor that would dilute the focus of this fix — flagging it so you are aware rather than surprising you at review time. Happy to open a follow-up refactor PR if you want the split.Test plan
bun run lint— cleanbun run typecheck— cleanbun test src/channels/__tests__/slack-formatter.test.ts— 20 pass, 0 failbun test— 857 pass, 2 fail (same 2 pre-existingphantom initenvironmental failures as every other branch)