Fix chats archive/unarchive hitting the wrong endpoint (silent no-op)#18
Fix chats archive/unarchive hitting the wrong endpoint (silent no-op)#18malob wants to merge 1 commit into
chats archive/unarchive hitting the wrong endpoint (silent no-op)#18Conversation
`chats archive` and `chats unarchive` called the generic chat-update
endpoint (PATCH /v1/chats/{chatID} with { isArchived }), which returns
200 OK but silently ignores isArchived — so the command reported success
while the chat's archive state never changed.
Switch both commands to the dedicated archiveChat endpoint
(POST /v1/chats/{chatID}/archive with { archived }) via the SDK's
client.chats.archive(chatID, { archived }), so the state actually changes.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📜 Recent review details🔇 Additional comments (3)
📝 WalkthroughSummary by CodeRabbit
WalkthroughThis PR fixes the ChangesArchive/unarchive endpoint fix
🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
beeper chats archive --chat <id>andbeeper chats unarchive --chat <id>reportsuccess: true/200 OK, but the chat's archive state never changes —chats show --chat <id> --json | jq '.data.isArchived'stays the same and the chat never moves in/out ofchats --archived. The success message is misleading.Root cause
Both commands called the generic chat-update endpoint with an
isArchivedfield:isArchivedis not a writable field on that endpoint, so the API returns200and ignores it.The Desktop API has a dedicated archive endpoint (OpenAPI
operationId: archiveChat, frombeeper api get /v1/spec):Note the three differences: POST (not PATCH), the
/archivesub-path, and the fieldarchived(notisArchived).Fix
Switch both commands from
client.chats.update(chatID, { isArchived })to the SDK's dedicatedclient.chats.archive(chatID, { archived }), which posts to/v1/chats/{chatID}/archive. That endpoint returns no body, so the commands now report viaprintSuccess(matching thechats remind/chats unremindconvention for void-returning actions) instead of printing the update response.No SDK bump required —
@beeper/desktop-apialready exposesclient.chats.archive(and the repo already encoded this expectation:scripts/check-api-copy.tsallowlistschats.archive, andtest/fixtures/fake-client.tsalready mocks it). The commands were simply wired to the wrong method.Verification
Built locally and ran against Beeper Desktop (
http://127.0.0.1:23373) on a throwaway chat.Before (buggy) —
chats archive --debug: wrong request, and a no-op:After (fixed) —
chats archive --debug: correct request, state actually changes:chats unarchivebehaves symmetrically ({ archived: false }→isArchived: false, leaveschats --archived). I archived → unarchived → re-archived the test chat and confirmed each transition via bothchats showandchats --archivedmembership, and that--debugnow shows the POST to/archivewith the misleading PATCH gone.Tests
@beeper/cli, patch).bun run test(build + readme/api-copy/manifest checks + cli-smoke +bun test) passes.fake-clientfixture is currently unused and no test instantiates commands), so I didn't add a bespoke harness;test/e2e-staging.tsalready exerciseschats archive/unarchiveand now drives the corrected endpoint.🤖 Generated with Claude Code