fix(parser): handle RTF-only message bodies without crashing - #5
Merged
Conversation
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 0049009. Configure here.
tinawu0603
force-pushed
the
tinawu/fix-rtf-binary-nullstrip
branch
from
June 6, 2026 03:50
0049009 to
2df070e
Compare
### What happened Some Outlook .msg files store the body only as compressed RTF, with no HTML or plain-text copy — common for automated mail where the real content is in the attachments. Parsing those crashed with "Unknown type of RTF compression!", which dropped the whole file (subject, sender, recipients, attachments) even though all of it was readable. ### The fix Two bugs. Binary properties were getting their null bytes stripped, but those bytes are real data — the compressed-RTF stream is full of them, and removing them shifted the header so the decompressor choked. Binary values are now left untouched. The decompressed body also came back as raw RTF bytes nothing decoded; it's now turned into clean plain text (empty when the RTF carries no content), matching the HTML and plain-text paths. Adds striprtf to the rtf extra. ### Evidence A real .msg that used to throw the RTF error now parses with all 9 attachments preserved and a correctly empty body. Existing parse and msg-to-eml tests still pass, non-RTF output is byte-identical, and a new test pins the null-byte behavior so an upstream re-sync can't silently reintroduce it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
tinawu0603
force-pushed
the
tinawu/fix-rtf-binary-nullstrip
branch
from
June 6, 2026 04:10
2df070e to
e15b64f
Compare
tinawu0603
commented
Jun 6, 2026
| max-parallel: 4 | ||
| matrix: | ||
| python-version: [2.7, 3.5, 3.6, 3.7] | ||
| python-version: ["3.14"] |
Author
There was a problem hiding this comment.
This is the actual python version we're running, let's just set it in CI for this fork that's only used by us
tinawu0603
marked this pull request as ready for review
June 6, 2026 04:13
giladlevy7
approved these changes
Jun 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What happened
Some Outlook .msg files store the body only as compressed RTF, with no HTML or plain-text copy — common for automated mail where the real content is in the attachments. Parsing those crashed with "Unknown type of RTF compression!", which dropped the whole file (subject, sender, recipients, attachments) even though all of it was readable.
The fix
Two bugs. Binary properties were getting their null bytes stripped, but those bytes are real data — the compressed-RTF stream is full of them, and removing them shifted the header so the decompressor choked. Binary values are now left untouched. The decompressed body also came back as raw RTF bytes nothing decoded; it's now turned into clean plain text (empty when the RTF carries no content), matching the HTML and plain-text paths. Adds striprtf to the rtf extra.
Evidence
A real .msg that used to throw the RTF error now parses with all 9 attachments preserved and a correctly empty body. Existing parse and msg-to-eml tests still pass, non-RTF output is byte-identical, and a new test pins the null-byte behavior so an upstream re-sync can't silently reintroduce it.
Testing
Video of a MSG that worked before and after, ensuring no regression
Screen.Recording.2026-06-05.at.23.04.16.mov
Video of the file broken in prod but working locally after this change when pointing backend-service to use the locally updated msg_parser package
Screen.Recording.2026-06-05.at.23.02.45.mov
File broken in prod
