include ping and error in RawMessageStreamEvent

[shiqicao]

ping and error are valid events, but they are not defined in RawMessageStreamEvent, this makes handling raw event not very friendly.

[RobertCraigie]

We don't include ping or error because the SDK will never yield those events. Are you asking because you're parsing the SSE stream without using the SDK?

[manucorporat]

@RobertCraigie I think it's still value to receive the ping events in the async iterator, it's useful for detecting if the connection is still alive during a long tool call, and distinguish from the API hanging, and not emitting more tokens.

[kolkov]

Cross-referencing #998, which builds on this thread and proposes a concrete fix (plus follow-up architecture) for ping handling in the SDK.

The 11-month gap since @manucorporat's comment has only made the downstream impact worse — Claude Code CLI's watchdog is currently consuming 40+ user reports in a 24-hour window (claude-code#46987) because it cannot distinguish Opus extended thinking from a silent hang. Every downstream reliability tool built on top of the SDK hits the same wall for the same reason — the ping event is Anthropic's own liveness signal, and dropping it on the SDK boundary turns it into a wasted contract.

#998 covers:

1. A minimal type-safe patch to forward ping as { type: 'ping', timestamp }.
2. A follow-up path toward semantic pings (status, queuePosition, thinkingDepth, nextPingWithinMs) so timeouts stop being client-side guesses.
3. Why this needs to live in the SDK (MIT, auditable, one implementation) rather than be reimplemented per-client.

Would love your take, @RobertCraigie.