fix: handle rate_limit_event message type

[dotuananh0712]

Summary

Add support for rate_limit_event messages from Claude Code CLI. This prevents MessageParseError from crashing the receive_messages() generator when rate limit events occur.

Changes

1. types.py: Added RateLimitEvent dataclass with fields:

   • type: The message type
   • session_id: Session identifier
   • limit_type: Type of limit (e.g., "turns", "tokens")
   • limit: The limit value
   • remaining: Remaining quota
   • reset_at: When the rate limit resets

2. message_parser.py: Added handler for rate_limit_event case in the match statement, parsing the event data into a RateLimitEvent object.

Problem

The CLI emits rate_limit_event messages which weren't recognized by the SDK's message parser. This caused MessageParseError("Unknown message type: rate_limit_event") to be raised inside the async generator, terminating it entirely.

Fixes

Fixes #583

---

This PR was contributed by an AI assistant (OpenCode).

[gspeter-max]

Great work on implementing Part 1 of the fix! 🙌 Adding the RateLimitEvent dataclass and parser case looks solid.

💡 Suggestion: Add Forward Compatibility (Part 2)

I noticed this PR addresses Part 1 (adding rate_limit_event support), but the issue also suggested Part 2: making unknown message types non-fatal for forward compatibility.

Why This Matters

Currently, the code still has the strict allowlist that crashes on unknown types. This means any future unknown message type from the CLI will still crash the SDK. The issue reporter emphasized this is particularly severe because it makes the SDK fragile against CLI updates.

Suggested Addition

Consider adding error handling in client.py receive_messages() to catch MessageParseError and skip unknown types with a warning log. This would handle all future unknown message types gracefully and prevent crashes from CLI updates.

Happy to submit a PR for this part if you'd like, or feel free to add it yourself!

[dotuananh0712]

Hi @gspeter-max

I've created a follow-up PR (#593) that adds forward compatibility by catching MessageParseError in the message loop and logging a warning instead of crashing. This way the SDK will gracefully handle any future unknown message types from the CLI without requiring code changes

#593

[gspeter-max]

@dotuananh0712 okay, now I think it ready for merge and solve the issue , wait for maintainers response