fix: guard unreadResp.data against null in channel threads command

[lmjabreu]

What

tw channel threads <name> --json crashed with:

{"error":{"code":"INTERNAL_ERROR","message":"Cannot read properties of undefined (reading 'map')"}}

Root cause

src/commands/channel/threads.ts:89 called .map() directly on unreadResp.data with no null guard:

const unreadThreadIds = new Set(unreadResp.data.map((u) => u.threadId))

The SDK's client.batch() returns { code, data: null } when a sub-request fails or when getUnread returns no data (e.g. the user has zero unread threads in the workspace). Calling .map() on null throws.

Fix

One-line change — add ?? [] so a null/undefined data falls back to an empty set, treating all threads as read:

const unreadThreadIds = new Set((unreadResp.data ?? []).map((u) => u.threadId))

assertBatchData() was intentionally not used here — having no unread threads is a valid state, not an error.

Test

Added a regression test to the existing src/commands/channel/threads.test.ts that mocks the batch response with data: null for the unread sub-request and asserts the command resolves without throwing, with all threads marked isUnread: false.

Verification

• npm run type-check ✅
• npm test ✅ (587 tests, 0 failures)
• Repro command: tw channel threads "Doist Component Library" --no-spinner --json

[doistbot]

This PR nicely fixes a crash in the channel threads command by adding a necessary null guard to the unread threads response. The implementation correctly handles valid empty states, and the included regression test ensures this stability is maintained. A few additional adjustments are recommended, specifically applying this same null guard to the inbox command, using assertBatchData on the primary threads response to prevent a similar crash, and simplifying the test mock setup by updating the setupClient helper.

_{Share Feedback • Review Logs}

[scottlovegrove]

Hey @lmjabreu — pushed a follow-up commit on top of your fix now that #159 is merged.

Quick summary of the adjustments:

• Added a getOptionalBatchData helper in src/lib/api.ts so the "null = valid empty state" pattern is reusable (and consistent with #159's helpers).
• Used assertBatchData on threadsResp so a failed getThreads sub-request surfaces a clean error instead of crashing the same way unreadResp did.
• Applied the same getOptionalBatchData treatment to the unread response in inbox.ts, which was actually crashing under the same conditions after fix: surface batch API errors in commands #159 landed.
• Refactored the regression test to use setupClient({ unread: null }), plus added tests for the new error/empty paths.
• Documented the four batch helpers (and when to use each) in AGENTS.md.

Functionally your original fix is preserved — the new helper just makes the pattern explicit and reusable.

[doist-release-bot]

🎉 This PR is included in version 2.36.5 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[frankieyan]

✅