Repository navigation
fix(buttondown): include Buttondown's bounded reason when it refuses a request - #2534
Merged
Merged
Conversation
…a request Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wn5rjyY9Z7Vhoc9QyGXToG
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
3 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.
The first live
post-public-updaterun onmainfailed withcreating the draft returned 422and nothing else. The lookups before the create succeeded, so the key and the network path work; Buttondown refused the create itself. Buttondown's docs don't say what a 422 means on that endpoint, and the client discarded the response body that would.Change: when Buttondown refuses a GET or the draft POST, the error now carries Buttondown's own reason, taken from the JSON body:
code/detail/messageif present, otherwise the JSON itself. It is collapsed to one line and capped at 300 characters, and a body that isn't JSON adds nothing. 5xx and 429 still go to the retry path and are never logged.Why it's safe to log (the repo's Actions logs are public): the key travels only in the Authorization header. Everything else the request sends is the public update (subject, markdown, the tag-id filter). Retry-path bodies are not logged.
Checked: two new tests, 19 in all. One covers a refusal's reason, bounded and on one line, with the key absent; the other covers a refusal without JSON, which reports the status alone.
scripts/gate.sh lint typesis clean.Review: security-reviewer found no blockers and called it safe to merge. I took its nit on the docstring, which now states that headers aren't echoed as an assumption, with the 300-character cap as the backstop. One recommendation is left as is: logging only
codeon 401/403. An account or plan refusal could name the account's sending address or username, but both are already public on the newsletter.Left for the maintainer rather than self-merged: it changes what a credentialed job writes to a public log.
Effect check after promotion: re-dispatch
gh workflow run post-public-update.yml --ref main -f week=2026-W41. If it still fails, the step log line now readscreating the draft returned 422: <Buttondown's reason>.Generated by Claude Code