Add comprehensive tests for MIME header special character and RFC 2047 handling

[faizan-2022]

This PR adds unit test coverage for MIME header parsing with a focus on Unicode characters, RFC 2047 encoded words, and edge-case robustness, ensuring correct and spec-compliant behavior of the header parser.

The tests validate that headers containing non-ASCII content are parsed safely and accurately without regressions or runtime errors.

1️⃣ What’s Covered 📋

Unicode & Internationalization

Emoji in subjects (📧, 🎉)

Non-ASCII scripts (日本語, العربية, עברית)

Mixed-script subjects

RFC 2047 Encoded Words

Base64 encoded subjects (=?UTF-8?B?...?=)

Quoted-printable encoded subjects (=?UTF-8?Q?...?=)

Multiple encoded words in sequence (RFC-compliant whitespace handling)

Mixed encoded and plain text subjects

Edge Cases & Robustness

Very long subject headers (>998 characters)

Folded headers (CRLF / LF continuation per RFC 2822)

Special IMAP characters in subjects

Graceful handling of malformed headers (no crashes, invalid lines ignored)

Utilities

Direct test coverage for header unfolding behavior

2️⃣ Acceptance Criteria Validation ✅

Unicode characters display correctly

RFC 2047 encoded words decode as expected

Long and folded headers are handled without truncation

Malformed headers do not throw or crash the parser

3️⃣ Notes 📝

Tests follow existing unit test structure and conventions

No production code changes were required

All behavior aligns with RFC 2047 and RFC 2822 specifications

4️⃣ Test Results 📊

All new and existing unit tests pass

No regressions observed

---

Important

Add comprehensive unit tests for MIME header parsing and Gmail label handling, ensuring robust handling of Unicode, RFC 2047, and edge cases.

• Tests:
  • Add header-parser.test.ts for MIME header parsing with Unicode, RFC 2047, and edge cases.
  • Add gmail-labels.test.ts for Gmail-specific label handling.
• MIME Header Parsing:
  • Handles Unicode (emoji, non-ASCII scripts, mixed scripts).
  • Decodes RFC 2047 base64 and quoted-printable encoded words.
  • Manages long subjects, folded headers, special IMAP characters, and malformed headers.
• Gmail Labels:
  • Parses Gmail system labels and custom labels with spaces, nesting, and special characters.
• Utilities:
  • Tests unfoldHeaders utility for CRLF and LF header unfolding.
• Misc:
  • No production code changes.
  • All tests pass with no regressions.

^{This description was created by for 65c0050. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to bd0c9a5 in 1 minute and 43 seconds. Click for details.

• Reviewed 111 lines of code in 2 files
• Skipped 2 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. package.json:117

• Draft comment:
  Consider adding a trailing newline at the end of package.json for consistency and linting compliance.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment is about the actual change in the diff (removal of trailing newline). However, I need to consider the rules: 1) This is a very minor stylistic issue, 2) The comment mentions "linting compliance" - if this were actually a linting issue, it would be caught by the build/linting tools automatically, 3) The rules state "Do NOT comment on anything that would be obviously caught by the build", 4) The rules also say "Do NOT make comments that are obvious or unimportant" - a missing trailing newline is quite minor. The comment is technically about a change, but it's the kind of thing that automated linting would catch if it were actually required. The comment is technically about a real change in the diff, and trailing newlines can be a legitimate style convention. Some projects do enforce this through linting, and it's not always automatically caught. The comment is actionable and specific. While trailing newlines can be a convention, the rules explicitly state not to comment on things that would be caught by the build. If this project enforces trailing newlines via linting, it would fail the build. If it doesn't enforce it, then this is an unimportant stylistic comment. Either way, this falls under "obvious or unimportant" comments that should be avoided. This comment should be deleted. It's about a minor stylistic issue (trailing newline) that would either be caught by automated linting if it were actually required, or is unimportant if not enforced. This violates the rules about not commenting on obvious/unimportant issues and things caught by the build.

2. tests/unit/header-parser.test.ts:93

• Draft comment:
  Add a trailing newline at the end of the test file to follow best practices.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This comment is about a very minor style issue - adding a trailing newline. While this is technically a "best practice" in many style guides, it falls into the category of "obvious or unimportant" comments. Many linters and formatters would automatically handle this, and it's not a functional issue. The rules explicitly state "Do NOT make comments that are obvious or unimportant." A missing trailing newline is extremely minor and would likely be caught by automated tooling if the project cares about it. This doesn't require human review attention. Some projects do enforce trailing newlines via linters (like ESLint or Prettier), and if this project has such rules, the comment might be catching a real issue. However, if it were enforced by tooling, the build would catch it, and the rules say not to comment on things that would be caught by the build. Even if the project enforces trailing newlines, this would be caught by automated tooling during the build process. The rules explicitly state "Do NOT comment on anything that would be obviously caught by the build." Additionally, this is an extremely minor style issue that falls under "obvious or unimportant" comments that should be avoided. This comment should be deleted. It's about a trivial style issue (missing trailing newline) that would either be caught by automated tooling or is too minor to warrant human review attention. It violates the rule against making obvious or unimportant comments.

Workflow ID: wflow_iIoaXMpTKJo4LggR

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[akberc]

Good.

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 65c0050 in 35 seconds. Click for details.

• Reviewed 109 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 3 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. tests/unit/gmail-labels.test.ts:32

• Draft comment:
  Consider asserting more details of the [Gmail] node’s structure (such as verifying the exact children keys) to ensure the parser’s behavior is fully as expected.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

2. tests/unit/gmail-labels.test.ts:57

• Draft comment:
  The nested label test is good; consider adding another case with deeper or multi-level nesting to further validate parser behavior.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

3. tests/unit/gmail-labels.test.ts:86

• Draft comment:
  For the 'special characters' label test, consider asserting additional properties (if relevant) to verify that other label fields (like attributes or delimiter) are handled correctly.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

Workflow ID: wflow_7L4pc6FPxeKtS9hJ

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}