Parser skips batchexecute error frame tag "e" — misses size-limit errors (code 132)

[N4IRS]

NotebookLM batchexecute uses tag "e" for error frames (e.g. ["e",4,null,null,132] when the question exceeds ~5489 chars), but _chat/wire.py only checks tag == "er". The "e" frame gets silently skipped, the wrb.fr chunk arrives with null inner JSON, and at zero parseable chunks the parser reports "No parseable chunks... API wire format may have changed" instead of surfacing the real error code 132. Adding tag == "e" alongside tag == "er" in _raise_chat_error_frame would surface these errors.
notebooklm_error_tag_e_findings.md

[teng-lin]

Fixed in #1636 (b667c751) — thanks for the investigation, the core symptom you identified was exactly right: an oversized question collapsed into the generic "No parseable chunks / API wire format may have changed" instead of surfacing the real rejection. That no longer happens; an over-long question now raises a clear ChatError telling you to shorten it.

One correction on the mechanism, since it changed where the fix landed. The rejection isn't actually carried by the "e" frame, and we deliberately did not add tag == "e" alongside tag == "er":

• ["e", ...], ["di", ...] and ["af.httprm", ...] are batchexecute stream bookkeeping frames. Their trailing number is a running byte count, not an error code — so the 132 in ["e",4,null,null,132] is a byte offset, not "code 132". Treating the "e" frame as an error would misfire on normal, successful chats (it's emitted on the happy path too).
• The real signal is the wrb.fr frame that arrives with a null inner JSON at item[2] and a grpc-style status payload at item[5] (3 = INVALID_ARGUMENT). The old parser skipped null-inner wrb.fr chunks, which is why every rejection degraded into the generic error.

So the fix surfaces the rejection from item[5] of that null-inner wrb.fr frame rather than from the "e" frame. The handling and the reasoning are documented inline in src/notebooklm/_chat/wire.py (the block around the # (issue #1472) comment), and "er" frames are still surfaced separately via _raise_chat_error_frame.

Net result for the reported case: oversized questions now fail loudly with an actionable message instead of a confusing parse error. Closing this out as resolved — please reopen if you still see a silent parse failure on current main.