fix(sdk): blocked reason is operator-only, not an API-returned field#54
Open
tuyakhov wants to merge 1 commit into
Open
fix(sdk): blocked reason is operator-only, not an API-returned field#54tuyakhov wants to merge 1 commit into
tuyakhov wants to merge 1 commit into
Conversation
senderkit-app's message read endpoints (GET /api/v1/messages and GET /api/v1/messages/:id) project a lean column set that never includes the detailed abuse `blockedReason` — the anti-phishing/spam signal breakdown is deliberately operator-only so a sender can't learn how detection works. App #211 locks this in (test-guarded across list, get, and the SSE tail). A prior release documented an optional `Message.blockedReason` field as if the API returned it; it never did. Correct the SDK surface to match reality: - types.ts: remove the `Message.blockedReason` field and reword the `status` doc. The `[key: string]: unknown` index signature is unchanged, so this is not a runtime change for callers. - mcp-schemas.ts: drop the MESSAGE_STATUSES comment claiming the trigger is on the message's `blockedReason`. The `blocked` lifecycle status itself is unaffected — still a real returned `status` value, still in MESSAGE_STATUSES and the messages_list status filter. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GL2Utmx3RszZ1uUQyLEzwu
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
Periodic sync review of
senderkit-appmainsince the last SDK sync (SDK PR #44, which covered app #196 — theblockedstatus). New app PRs reviewed: #197 → #211. One of them, senderkit-app #211 ("keep spam-detection detail out of customer-visible surfaces"), directly contradicts a field the SDK currently documents.The issue
SDK PR #44 added an optional
Message.blockedReasonfield, documented as "the human-readable reason ablockedmessage was halted." But the app's message read endpoints never returned it:getMessage/listMessages(backingGET /api/v1/messages/:idandGET /api/v1/messages) project an explicitmessageColumnsset that does not includeblockedReason— and never has.blockedReasonis absent from the list/get projection and the SSE tail.So
Message.blockedReasonadvertised a field that is never populated on any SDK/MCP/CLI response.Changes (SDK)
packages/sdk/src/types.ts— remove theMessage.blockedReasonfield and reword thestatusdoc to note the block reason is operator-only / not returned. The[key: string]: unknownindex signature is unchanged, so this is not a runtime change for any caller.packages/sdk/src/mcp-schemas.ts— drop theMESSAGE_STATUSEScomment claiming the trigger lives on the message'sblockedReason.@senderkit/sdkpatch +@senderkit/clipatch.Not changed (intentionally)
blockedlifecycle status stays — it's a real, returnedstatusvalue, kept inMESSAGE_STATUSESand thesenderkit_messages_list.statusfilter (added in feat(sdk): add theblockedmessage status from outbound abuse scanning #44, still correct).Other app PRs reviewed — no SDK/CLI/MCP action needed
senderkit_supabase_*)@senderkit/sdkis untouched — these are app-internal management tools, not SDK manifest surfaceGET /api/v1/messages?cursor=…¹ #211 is the abuse PR that triggered this SDK doc correction (above).
Verification
pnpm build,pnpm typecheck(all packages incl. examples), and tests pass — 58 sdk + 80 cli green.🤖 Generated with Claude Code
Generated by Claude Code