Marco Beretta 7a923ef404 fix: cap forced-retention edits to the message's earlier expiry ... The edit/feedback path calls applyForcedRetention with capExpiryToConversation, which unconditionally set the touched message's expiredAt to the parent/fresh forced deadline. When that message already expired sooner (an older message keeps its creation-time deadline while later saves refreshed the parent's), the $set extended it past its own schedule, overwriting the earlier deadline that capForcedRetentionToParent had just preserved. Cap the touched message to min(existing expiredAt, forcedExpiredAt) via the same $min/$ifNull pipeline forceConversationMessagesTemporary already uses, so a message with a sooner deadline keeps it and a permanent message still receives the forced one.		2026-07-03 21:26:41 +02:00
..
api	fix: enforce ephemeral retention on chat project membership changes	2026-07-03 15:03:09 +02:00
client	🧪 ci: Resolve DataTable test infinite re-render (#13947)	2026-06-24 23:40:18 -04:00
data-provider	feat: add ephemeral retention mode for forced temporary chats	2026-06-30 04:51:45 +02:00
data-schemas	fix: cap forced-retention edits to the message's earlier expiry	2026-07-03 21:26:41 +02:00