[M3gA-Mind]

Summary

• Bound Gmail GMAIL_FETCH_EMAILS HTML post-processing to 512 KiB UTF-8 before noise stripping and the fast HTML→text pass.
• Emit tracing::warn! when truncation applies and append a short [Email HTML body truncated for processing] note to the markdown field.
• Align module / provider / test comments with the existing fast stripper path (no html2md).
• Add unit tests oversized_html_is_truncated_before_processing and truncated_all_whitespace_html_still_emits_truncation_note (truncation note when strip yields empty).
• CodeRabbit: preserve the truncation marker when cleaned is empty after strip.

Problem

During investigation of #982 (production macOS Intel unexpected quit), a crash report showed the faulting thread as tokio-rt-worker, in Composio Gmail periodic sync → html_email_to_markdown / legacy html2md table handling and runaway realloc, not the main-thread CEF SIGABRT described in the issue title. Large or pathological HTML MIME can still stress memory in strip passes without an input cap.

Solution

• Truncate oversized HTML at a UTF-8-safe boundary before strip_html_noise_blocks / fast_html_to_text.
• Log and surface truncation in the reshaped markdown payload so agents/users know content was clipped.

Submission Checklist

• Tests added or updated — oversized HTML cap + whitespace-only truncation note; existing Gmail post-process behaviour otherwise unchanged.
• Diff coverage ≥ 80% — pnpm test:coverage and pnpm test:rust completed locally (exit 0).
• Coverage matrix — N/A: small Rust-only composio post-process change.
• Related feature matrix — N/A: no matrix row change.
• No new external network dependencies.
• Manual smoke — N/A: core composio Gmail reshape only.

Impact

• Desktop core only: slimmer memory use when Composio returns very large HTML bodies; rare emails over 512 KiB HTML lose tail content (explicitly noted in output).

Related

• Closes Fix the production Mac Intel crash (EXC_CRASH/SIGABRT) in OpenHuman 0.53.4 #982
• Follow-up PR(s)/TODOs: If Fix the production Mac Intel crash (EXC_CRASH/SIGABRT) in OpenHuman 0.53.4 #982 repro is strictly main-thread CEF SIGABRT, track any remaining CEF-specific fix separately after verifying this worker-path crash is gone in telemetry.

Made with Cursor

Summary by CodeRabbit

• Bug Fixes
  • Gmail email extraction now prefers plain-text parts and falls back to a bounded HTML-to-text path for large HTML bodies; oversized HTML is truncated and a truncation notice is included in the output (even when the cleaned result is empty).
• Documentation
  • Updated Gmail sync docs to describe an HTML→text post-processing pipeline.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 8abe282b-945d-4bf5-b2f4-fa7497cce730

📥 Commits

Reviewing files that changed from the base of the PR and between 4e2ac43 and ef143aa.

📒 Files selected for processing (2)

• src/openhuman/composio/providers/gmail/post_process.rs
• src/openhuman/composio/providers/gmail/post_process_tests.rs

🚧 Files skipped from review as they are similar to previous changes (1)

• src/openhuman/composio/providers/gmail/post_process_tests.rs

---

📝 Walkthrough

Walkthrough

Gmail post-processing now prefers text/plain parts and falls back to a bounded, linear HTML→text stripper. HTML input is truncated to MAX_GMAIL_HTML_BODY_BYTES at UTF‑8 boundaries; truncation logs a warning and emits a truncation marker, including when stripping yields empty output.

Changes

Gmail Post-Processing Truncation and HTML Extraction

Layer / File(s)	Summary
Data Shape & Constants src/openhuman/composio/providers/gmail/post_process.rs	Adds pub(super) const MAX_GMAIL_HTML_BODY_BYTES: usize and a UTF‑8-aware truncation helper to cap HTML input bytes before processing.
Core Implementation src/openhuman/composio/providers/gmail/post_process.rs	html_email_to_markdown now truncates HTML to the byte cap, warns via tracing::warn! on truncation, and appends/returns a truncation-note marker. Comments updated to document plaintext-first preference and a linear HTML stripper (no html2md).
Integration & Wiring src/openhuman/composio/providers/gmail/provider.rs	Module doc updated from “HTML→md” to “HTML→text” for the post_process_action_result pipeline to reflect the bounded stripper behavior.
Tests & Verification src/openhuman/composio/providers/gmail/post_process_tests.rs	Test comments adjusted to reflect plaintext-first behavior. New tests: oversized_html_is_truncated_before_processing (verifies head preserved, tail omitted, truncation note present) and truncated_all_whitespace_html_still_emits_truncation_note (ensures marker emitted when stripping yields empty body).

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Possibly related PRs

• fix(composio/gmail): phase out html2md, prefer text/plain MIME part #1170: Modifies the same Gmail post-processing logic (preference for text/plain, replacing html2md with linear HTML stripper, and truncation handling).
• feat(composio/gmail): sync into memory tree (Slack-parity) #1056: Previously touched Gmail HTML→text/markdown conversion used by post_process_action_result.

Suggested reviewers

• senamakel

Poem

I nibble bytes with careful paws,
Trim the tail without a pause,
Keep the start, note what was lost,
Fast and kind — no hidden cost. 🐇✂️

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Linked Issues check	❓ Inconclusive	PR implements defensive handling (HTML size cap + truncation logging) as specified in #982, addressing the suspected crash path in Gmail post-processing without fully addressing Intel-specific investigation objectives.	Clarify whether the HTML truncation mitigation alone satisfies #982's root cause investigation or if additional Intel-specific diagnostics are required before closing the issue.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	Title clearly identifies the main change: capping Gmail HTML body size before stripping for crash mitigation.
Out of Scope Changes check	✅ Passed	All changes directly support the bounded HTML processing and truncation-note behavior for the Gmail post-processor; documentation updates align with implementation.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Review rate limit: 4/5 reviews remaining, refill in 12 minutes.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

src/openhuman/composio/providers/gmail/post_process_tests.rs (1)

289-303: ⚡ Quick win

Use the production cap constant in the truncation test.

Hardcoding 512 * 1024 makes this test drift-prone if the cap changes. Reusing MAX_GMAIL_HTML_BODY_BYTES keeps intent locked to behavior.

💡 Suggested tweak

 fn oversized_html_is_truncated_before_processing() {
-    const CAP: usize = 512 * 1024;
+    const CAP: usize = MAX_GMAIL_HTML_BODY_BYTES;
     let filler = "x".repeat(600 * 1024);
@@
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/openhuman/composio/providers/gmail/post_process_tests.rs` around lines
289 - 303, The test hardcodes CAP (512 * 1024) instead of using the production
constant MAX_GMAIL_HTML_BODY_BYTES; update the test in post_process_tests.rs to
reference MAX_GMAIL_HTML_BODY_BYTES (import it if necessary) when computing the
cap and the filler length so the generated html exceeds
MAX_GMAIL_HTML_BODY_BYTES, and keep assertions (html_email_to_markdown,
HEAD_MARKER, TAIL_NEVER_SEEN, and truncation note) unchanged.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/openhuman/composio/providers/gmail/post_process.rs`:
- Around line 283-289: The code currently returns early when `cleaned` is empty,
so the `truncated` marker is never appended; change the logic to always
construct an `out` string and only populate it from
`normalize_markdownish_text(&fast_html_to_text(cleaned))` when `cleaned` is
non-empty, then if `truncated` is true append "\n\n[Email HTML body truncated
for processing]" to `out` and return it; update the block around `cleaned`,
`out`, `normalize_markdownish_text`, `fast_html_to_text`, and `truncated`
accordingly so the truncation note is preserved even when `cleaned` is empty.

---

Nitpick comments:
In `@src/openhuman/composio/providers/gmail/post_process_tests.rs`:
- Around line 289-303: The test hardcodes CAP (512 * 1024) instead of using the
production constant MAX_GMAIL_HTML_BODY_BYTES; update the test in
post_process_tests.rs to reference MAX_GMAIL_HTML_BODY_BYTES (import it if
necessary) when computing the cap and the filler length so the generated html
exceeds MAX_GMAIL_HTML_BODY_BYTES, and keep assertions (html_email_to_markdown,
HEAD_MARKER, TAIL_NEVER_SEEN, and truncation note) unchanged.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 2583c7cf-324d-480c-80dd-dc2a20922642

📥 Commits

Reviewing files that changed from the base of the PR and between 995669f and 4e2ac43.

📒 Files selected for processing (3)

• src/openhuman/composio/providers/gmail/post_process.rs
• src/openhuman/composio/providers/gmail/post_process_tests.rs
• src/openhuman/composio/providers/gmail/provider.rs