add published_in_epoch to group message

[insipx]

• add published_in_epoch column to group message
• requires companion pr in xmtp/proto
• sets the epoch of a group_message when storing in the database.

This will help ensure message dependencies can be programmed defensively by ensuring the epoch of a commit is 1 less then the message we are setting a dependency on.

[insipx]

This PR is part of a stack of 11 bookmarks:

1. trunk()
2. insipx/dependency-resolution
3. insipx/causal-sort
4. insipx/resolution
5. insipx/network-backoff
6. insipx/ordered-combinator
7. insipx/test-resolution
8. insipx/test-ordering
9. insipx/add-published-in-epoch ← this PR
10. insipx/sql-queries
11. insipx/sync-conn
12. insipx/set-dependencies

---

Created with jj-stack

[claude]

Claude finished @insipx's task —— View job

---

Code Review Complete

Review Date: November 21, 2025 00:16 UTC

I've reviewed this PR which adds the published_in_epoch column to group messages. The implementation is solid overall with good test coverage. Here are my findings:

✅ Strengths

• Clean database migration with proper up/down scripts
• Consistent field propagation through all layers (DB → proto → ORM → MLS)
• Proper handling as Option<i64> allowing backward compatibility
• Good test coverage (all modified lines covered per Codecov)
• Field correctly populated in both process_group_message (line 1089) and save_transcript_message (line 2021) in xmtp_mls/src/groups/mls_sync.rs

🔍 Observations

1. Schema Inconsistency (Minor)
The group_intents table already has a published_in_epoch column (xmtp_db/src/encrypted_store/schema_gen.rs:43), but there's no corresponding update or validation logic ensuring the epoch on an intent matches the epoch on its resulting message. Since the PR description mentions "ensuring the epoch of a commit is 1 less than the message we are setting a dependency on," consider whether intents and their messages should have matching epochs.

2. Test Helper Gap
The test helper generate_message() in xmtp_db/src/encrypted_store/group_message/tests.rs:34 hardcodes published_in_epoch: None. While this works, future tests validating epoch-specific logic may need to pass this value explicitly. Consider adding it as an optional parameter.

3. Migration Timing
Migration file naming: 2025-11-18-174226-0000_group_message_epoch. The year appears to be 2025 which is unusual. Verify this is intentional or if it should be 2024.

Summary

The implementation correctly adds epoch tracking to messages as described. The concerns above are minor - the inconsistency observation is primarily for future work in the stack, and the test helper is purely a maintainability suggestion. No blocking issues found.

---

[tylerhawkes]

What can be done so that generation of these are stable and don't move around when we add more code?

[insipx]

we could try using https://docs.rs/tonic/latest/tonic/macro.include_proto.html

This would generate the protos into the rust OUT_DIR. the downside is first compile will be a bit longer as it needs to clone xmtp/proto and googleapis to generate the protos. but it will delete the entire gen/ directory, which will create smaller PRs.

at that point, i would argue for moving xmtp_proto, or at least just the "proto" part into xmtp/proto, then renaming xmtp_proto to xmtp_types or xmtp_primitives or something. Then we could get rid of the companion PR pattern and proto generation could just be a cargo update which makes versioning clearer (rather than ad-hoc commit refs we store in txt, cargo would take care of it in the lockfile)

[tylerhawkes]

I think we open an issue with prost. My guess is they're using some hash that is dependent on the contents of the protos and that's why things change around when a single field is added.

[macroscopeapp]

Add published_in_epoch to group messages and persist it from xmtp_mls::MlsGroup.process_group_message and xmtp_mls::MlsGroup.save_transcript_message into the group_messages.published_in_epoch BIGINT column

Introduce an optional epoch field on stored group messages, propagate it through proto, conversion, and ORM, and populate it during message processing and transcript saves; include DB migration adding published_in_epoch.

📍Where to Start

Start with the epoch capture and persistence in MlsGroup.process_group_message and MlsGroup.save_transcript_message in xmtp_mls/src/groups/mls_sync.rs.

---

Macroscope summarized cfd66ae.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.70%. Comparing base (6c66152) to head (695ab3c).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2805      +/-   ##
==========================================
+ Coverage   74.67%   74.70%   +0.02%     
==========================================
  Files         385      385              
  Lines       49762    49780      +18     
==========================================
+ Hits        37158    37186      +28     
+ Misses      12604    12594      -10     

☔ 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.