Use String for ContentType in Archives

[codabrink]

proto xmtp/proto#316

[claude]

Claude finished @codabrink's task —— View job

---

Code Review Complete

Review Date: January 15, 2026, 02:18 UTC

---

Summary

This PR migrates from enum-based to string-based content_type storage in GroupMessageSave for message backups. The implementation correctly handles backward compatibility by reading from the deprecated content_type_save field when the new content_type string is unknown.

Feedback

1. Fallback Logic Issue (xmtp_db/src/encrypted_store/group_message/convert.rs:14-17)

The fallback logic has a subtle bug. The current implementation:

let mut content_type: ContentType = value.content_type_save().into();
if matches!(content_type, ContentType::Unknown) {
    content_type = value.content_type.into();
}

Problem: This only falls back to content_type_save when parsing the new content_type string results in Unknown. However, if content_type is an empty string (the protobuf default), From<String> will return Unknown, triggering the fallback even for new backups where we should trust the string value.

Recommendation: Reverse the priority - try the new string field first, and only fall back to the enum if the string is empty:

let content_type = if value.content_type.is_empty() {
    value.content_type_save().into()
} else {
    value.content_type.into()
};

2. Missing Test Coverage

No tests verify the conversion between StoredGroupMessage ↔ GroupMessageSave, particularly:

• Content types that exist in the internal enum but not in the proto enum (e.g., WalletSendCalls, Markdown, etc.)
• Backward compatibility with old backups using content_type_save
• Round-trip conversion accuracy

Recommendation: Add unit tests in xmtp_db/src/encrypted_store/group_message/convert.rs or a separate test module.

3. Proto Design: Extensibility Concern

The ContentTypeSave enum is still present in the proto but deprecated. Future content types will only be string-based. This creates an asymmetry where:

• Old content types have both enum values and string representations
• New content types only have strings

Note: This is likely intentional for backward compatibility, but worth documenting that ContentTypeSave should never be extended with new variants.

4. Performance: String Operations

On line 104 of convert.rs, value.content_type.to_string() is called for every conversion. The Display impl for ContentType matches against all variants each time.

Consideration: This is likely negligible performance impact for typical backup operations, but could be optimized with memoization if this becomes a bottleneck in large exports.

5. Code Quality: Positive Observations

✅ Proper use of #[allow(deprecated)] for content_type_save
✅ Proto properly marks old field as deprecated
✅ Generated serde code handles both snake_case and camelCase field names
✅ Codecov confirms test coverage is maintained

---

Verdict

Approve with suggestions. The core implementation is sound, but the fallback logic priority should be reversed to avoid incorrectly treating empty strings as "Unknown". Test coverage for the conversion logic would strengthen confidence in backward compatibility.

---

[macroscopeapp]

Use a string content_type in GroupMessageSave and update convert.TryFrom<GroupMessageSave> for StoredGroupMessage and convert.From<StoredGroupMessage> for GroupMessageSave to map it directly

Replace enum-based content_type conversions with string-based assignments in GroupMessageSave and related converters, remove ContentType⇄ContentTypeSave converters, and update the generated proto and serde for content_type and deprecated content_type_save in xmtp_db/src/encrypted_store/group_message/convert.rs, xmtp_proto/src/gen/xmtp.device_sync.message_backup.rs, and xmtp_proto/src/gen/xmtp.device_sync.message_backup.serde.rs.

📍Where to Start

Start with the converters in xmtp_db/src/encrypted_store/group_message/convert.rs, focusing on impl TryFrom<GroupMessageSave> for StoredGroupMessage and impl From<StoredGroupMessage> for GroupMessageSave.

---

Macroscope summarized da09ccf.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.50%. Comparing base (6652a98) to head (aa32f3c).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3012      +/-   ##
==========================================
+ Coverage   74.29%   74.50%   +0.20%     
==========================================
  Files         413      416       +3     
  Lines       53389    54130     +741     
==========================================
+ Hits        39665    40329     +664     
- Misses      13724    13801      +77     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[codabrink]

This matches the From<String> for Content type impl.

[macroscopeapp]

Use a string content_type in xmtp.device_sync.message_backup.GroupMessageSave and update xmtp_db::encrypted_store::group_message::convert to derive ContentType from ContentTypeSave or the string fallback

Switch GroupMessageSave to a string content_type with deprecated content_type_save set to 0, make From<ContentTypeSave> non-fallible returning ContentType::Unknown, and update conversion to StoredGroupMessage to fall back to the string when the saved enum is Unknown. Update the proto version hash.

📍Where to Start

Start with the TryFrom<GroupMessageSave> for StoredGroupMessage implementation in xmtp_db/src/encrypted_store/group_message/convert.rs.

---

Macroscope summarized aa32f3c.