fix(sdk): stop advertising operator-only blockedReason on Message#51
Open
tuyakhov wants to merge 1 commit into
Open
fix(sdk): stop advertising operator-only blockedReason on Message#51tuyakhov wants to merge 1 commit into
tuyakhov wants to merge 1 commit into
Conversation
The customer-facing API (messages.list/get + the live tail) never returns the detailed abuse-scan trigger — it is operator-only and senderkit-app #211 made that explicit and permanent. Drop the optional `Message.blockedReason` field and the MCP status-description reference to it. A `blocked` message still surfaces a generic "blocked" entry on its timeline. The `Message` index signature keeps `.blockedReason` readable as `unknown`, so this is non-breaking. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AegJQ2qjCaw8iJjaAFni2k
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
2 participants
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.
Why
Routine sync review of
senderkit-appchanges merged tomainsince the last run (PRs #193–#211). All but one were internal (abuse-scanner refactors, billing/pricing, analytics, onboarding, admin UI, marketing copy) and need no SDK/CLI/MCP change. One app change affects this SDK:blockedReason) is now permanently operator-only: it is omitted from every customer-facing message read (messages.list/get, the SSE live tail, and the logs SSR fetch), and the message timeline records only a genericblockedentry. Senders must not learn how/whether detection runs.The SDK, however, still advertised
Message.blockedReason(added alongside theblockedstatus in the previous sync). Because the customer API never actually populated it, the field was always absent on the wire — so this corrects the type to match reality.Message read type (
packages/sdk/src/types.ts)blockedReason?: string | nullfield fromMessage.statusdoc comment: ablockedmessage is halted by the outbound abuse scanner and surfaces a generic"blocked"entry on itstimeline; the detailed detection breakdown is operator-only and never returned by the API.MCP (
packages/sdk/src/mcp-schemas.ts)MESSAGE_STATUSESdoc comment to drop theblockedReasonreference (same operator-only framing). Theblockedstatus itself is unchanged and still valid across the SDK, CLI, and MCP.CLI
No change required — the
messages getformatter never printedblockedReason.Compatibility
Non-breaking.
Messagekeeps its[key: string]: unknownindex signature, so any existingmsg.blockedReasonaccess still type-checks (asunknown) and resolves toundefined, exactly as it did at runtime before. Shipped as a patch with a changeset.Verification
pnpm -C packages/sdk build— DTS build successpnpm -C packages/sdk test— 58 passedpnpm -C packages/cli test— 80 passed (consumes theMessagetype)🤖 Generated with Claude Code
Generated by Claude Code