Summary

On a Gmail-connected workspace, inbound messages from certain sender hosts are imported with empty message.text while metadata (subject, participants, thread) is stored correctly. Contact (Person) detail pages consequently appear to "hide" those emails — they are in the DB but render blank/empty.

Environment

• Twenty version: 1.23.1
• Docker image: twentycrm/twenty:latest (built 2026-04-17)
• Self-hosted via Docker Compose (server + worker + postgres:16 + redis)
• Messaging provider: Gmail (MESSAGING_PROVIDER_GMAIL_ENABLED=true)
• 3 connected Gmail accounts, all syncStatus=ACTIVE, messageFolderImportPolicy=ALL_FOLDERS, visibility=SHARE_EVERYTHING

Reproduction

A person has 4 messages in the thread — 2 inbound (contact → us), 2 outbound (us → contact). All 4 rows exist in message, with correct messageParticipant rows linked to personId. However:

• 2 outbound messages (composed in Gmail web) → LENGTH(text) = 717 and 1437
• 2 inbound messages (sent from contact's Yandex mailbox) → LENGTH(text) = 0

Result: on the contact page, only the 2 outbound messages appear to display meaningful content.

Distribution across the mailbox

Out of 11,958 imported messages, 801 (~6.7%) have empty bodies. Grouped by headerMessageId host:

Hosts that send via non-Gmail infrastructure have a very high or 100% body-empty rate. Gmail-native messages mostly succeed (a small fraction fail too, likely HTML-only with no text/plain part).

Expected behavior

message.text should be populated with the message body (plain text extracted from the Gmail API payload parts), regardless of the sending MTA/client. When no text/plain part is present, the importer should fall back to converting text/html → plain text.

Actual behavior

message.text is stored as empty string for many inbound messages, predominantly from non-Gmail origins.

Related

• When syncing emails with Microsoft, only emails *sent* to the email-address set in the record are linked to the record. #14490 — closed as fixed Nov 2025, but "contact page only shows sent emails" symptom persists in 1.23.1. The underlying cause here (empty body rendering as blank card) is likely distinct from the original folder/import-policy fix.

Secondary observation

In this workspace, all 11,958 messages have direction='INCOMING', zero 'OUTGOING' — even messages clearly sent from a connected account (FROM = ownaccount@ourdomain, TO = external contact). The direction-assignment step of the Gmail importer appears to never produce OUTGOING. Possibly related, possibly a second bug — flagging for triage.