@remit/mailbox-service 0.0.93 → 0.0.94

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remit/mailbox-service",
-  "version": "0.0.93",
+  "version": "0.0.94",
   "type": "module",
   "main": "src/index.ts",
   "types": "src/index.ts",

package/src/body-sync-category-override.test.ts

@@ -343,8 +343,9 @@ describe("Address.flags.category overrides classification at sync time (issue #2
 		);
 
 		// The harness's default `retrieve` throws, so a storage read would fail
-		// this outright. Issue #415 is where applying the override to this message
-		// deliberately belongs; a sync pass is not it.
+		// this outright. Reaching back is the back-apply job's work (#415,
+		// `backApplySenderCategory`), fired by the flag PATCH; a sync pass is
+		// still not it.
 		assert.equal(result.skippedCount, 1);
 		assert.deepEqual(result.failedMessageIds, []);
 		assert.deepEqual(harness.messageUpdates, []);

package/src/body-sync.ts

@@ -62,6 +62,7 @@ import {
 	resolveBlockedVsTrust,
 } from "./heuristics/classifyPlacement.js";
 import { extractSenderMismatch } from "./heuristics/senderMismatch.js";
+import { denormalizeMessageCategory } from "./message-category.js";
 import type { PlacementMoveService } from "./placement-move.js";
 import { type QuarantineService, shapeFromMessageData } from "./quarantine.js";
 import { extractSnippetFromEmail } from "./snippet.js";
@@ -165,23 +166,6 @@ const extractSnippet = (parsed: ParsedMail): string =>
 		SNIPPET_LENGTH,
 	);
 
-/**
- * A row is skipped only when every field the denormalization would write
- * already matches. `snippet` and `listId` are absent from the update when the
- * message has neither, and an absent field is not a mismatch.
- */
-const alreadyDenormalized = (
-	row: ThreadMessageItem,
-	update: {
-		category: ThreadMessageCategory;
-		snippet?: string;
-		listId?: string;
-	},
-): boolean =>
-	row.category === update.category &&
-	(update.snippet === undefined || row.snippet === update.snippet) &&
-	(update.listId === undefined || row.listId === update.listId);
-
 /**
  * RFC 034 Decision 3.1: `Message.category` is written once and never mutated
  * after — RFC 030's message-list GSI sort key depends on it never churning.
@@ -928,12 +912,11 @@ export class BodySyncService {
 
 		// Thread-list denormalization, using the same write-once category as the
 		// Message update below — the two rows must never disagree on category.
-		await this.denormalizeCategory(
+		await denormalizeMessageCategory(
+			{ threadMessageService: this.threadMessageService },
 			accountConfigId,
 			messageId,
-			finalCategory,
-			snippet,
-			listId,
+			{ category: finalCategory, snippet, listId },
 		);
 
 		// `classificationState` records that the classifier ran, in the same
@@ -1891,73 +1874,4 @@ export class BodySyncService {
 			throw err;
 		}
 	}
-
-	/**
-	 * Write the denormalized `category` (and optionally the snippet and the
-	 * normalized `List-Id`) onto EVERY ThreadMessage row the message has — the
-	 * copy the list/search read path serves without a per-row Message fetch.
-	 *
-	 * More than one row per messageId is schema-legal but not normally produced,
-	 * and this iterates for the same reason `message-move.ts` does (see the model
-	 * stated at its `deleteThreadMessagesForMessage`): the key permits it and
-	 * nothing enforces otherwise. It is NOT the second mailbox a message appears
-	 * in — `deriveMessageId` and `deriveThreadMessageId` are both
-	 * mailbox-independent, so INBOX and Archive resolve to one row, and a copy
-	 * gets its own messageId. The reachable case is thread-root drift: the same
-	 * message re-saved under different `References`, which mints a second
-	 * threadId and so a second row. Iterating is therefore hardening against a
-	 * legal state, not a repair for one the sync path manufactures, which is why
-	 * the tree's other single-row `messageId` lookups are correct as they stand.
-	 * `flag-queue.ts` iterates the same list.
-	 *
-	 * Rows are looked up by messageId, so this does not depend on the RFC822
-	 * Message-ID header — a headerless message still gets denormalized, matching
-	 * the unconditional Message.category write. The composite set is built per
-	 * row, never reused: `mailboxId` and `isRead` can differ between two rows for
-	 * one message, and it is passed at all so that a future key-attribute
-	 * addition touching the lsi3/lsi4/lsi5/gsi2 sort keys keeps the index rows
-	 * consistent.
-	 */
-	private async denormalizeCategory(
-		accountConfigId: string,
-		messageId: string,
-		category: ThreadMessageCategory,
-		snippet?: string,
-		listId?: string,
-	): Promise<void> {
-		const rows = await this.threadMessageService.findAllByMessageId(
-			accountConfigId,
-			messageId,
-		);
-		if (rows.length === 0) {
-			throw new NotFoundError(
-				`ThreadMessage not found for message ${messageId}`,
-			);
-		}
-
-		const update = {
-			category,
-			...(snippet ? { snippet } : {}),
-			...(listId ? { listId } : {}),
-		};
-
-		for (const row of rows) {
-			if (alreadyDenormalized(row, update)) continue;
-			await this.threadMessageService.update(
-				accountConfigId,
-				row.threadMessageId,
-				update,
-				{
-					composites: {
-						sentDate: row.sentDate,
-						mailboxId: row.mailboxId,
-						isRead: row.isRead,
-						isDeleted: row.isDeleted,
-						hasStars: row.hasStars,
-						hasAttachment: row.hasAttachment,
-					},
-				},
-			);
-		}
-	}
 }

package/src/index.ts

@@ -193,6 +193,12 @@ export {
 	MailboxSyncService,
 	type SyncAccountInfo,
 } from "./mailbox-sync.js";
+export {
+	denormalizeMessageCategory,
+	type MessageCategoryDenormalizeDeps,
+	type MessageCategoryDenormalizeInput,
+	type MessageCategoryValue,
+} from "./message-category.js";
 export {
 	type DeleteMessagesOutcome,
 	type DeleteOptions,

package/src/message-category.ts

@@ -0,0 +1,100 @@
+import type {
+	IThreadMessageRepository,
+	ThreadMessageItem,
+} from "@remit/data-ports";
+import { NotFoundError } from "@remit/data-ports/errors";
+
+export type MessageCategoryValue = ThreadMessageItem["category"];
+
+export interface MessageCategoryDenormalizeDeps {
+	threadMessageService: Pick<
+		IThreadMessageRepository,
+		"findAllByMessageId" | "update"
+	>;
+}
+
+export interface MessageCategoryDenormalizeInput {
+	category: MessageCategoryValue;
+	snippet?: string;
+	listId?: string;
+}
+
+/**
+ * A row is skipped only when every field the denormalization would write
+ * already matches. `snippet` and `listId` are absent from the update when the
+ * message has neither, and an absent field is not a mismatch.
+ */
+const alreadyDenormalized = (
+	row: ThreadMessageItem,
+	update: MessageCategoryDenormalizeInput,
+): boolean =>
+	row.category === update.category &&
+	(update.snippet === undefined || row.snippet === update.snippet) &&
+	(update.listId === undefined || row.listId === update.listId);
+
+/**
+ * Write a message's category (and, when the caller has them, its snippet and
+ * `List-Id`) onto every ThreadMessage row that indexes it. The thread row is
+ * what the message list renders and what the category filter matches, so it
+ * must never disagree with the Message row it mirrors.
+ *
+ * More than one row per messageId is schema-legal but not normally produced,
+ * and this iterates for the same reason `message-move.ts` does (see the model
+ * stated at its `deleteThreadMessagesForMessage`): the key permits it and
+ * nothing enforces otherwise. It is NOT the second mailbox a message appears
+ * in — `deriveMessageId` and `deriveThreadMessageId` are both
+ * mailbox-independent, so INBOX and Archive resolve to one row, and a copy
+ * gets its own messageId. The reachable case is thread-root drift: the same
+ * message re-saved under different `References`, which mints a second
+ * threadId and so a second row. Iterating is therefore hardening against a
+ * legal state, not a repair for one the sync path manufactures, which is why
+ * the tree's other single-row `messageId` lookups are correct as they stand.
+ * `flag-queue.ts` iterates the same list.
+ *
+ * Rows are looked up by messageId, so this does not depend on the RFC822
+ * Message-ID header — a headerless message still gets denormalized, matching
+ * the unconditional Message.category write. The composite set is built per
+ * row, never reused: `mailboxId` and `isRead` can differ between two rows for
+ * one message, and it is passed at all so that a future key-attribute
+ * addition touching the lsi3/lsi4/lsi5/gsi2 sort keys keeps the index rows
+ * consistent.
+ */
+export const denormalizeMessageCategory = async (
+	deps: MessageCategoryDenormalizeDeps,
+	accountConfigId: string,
+	messageId: string,
+	update: MessageCategoryDenormalizeInput,
+): Promise<void> => {
+	const rows = await deps.threadMessageService.findAllByMessageId(
+		accountConfigId,
+		messageId,
+	);
+	if (rows.length === 0) {
+		throw new NotFoundError(`ThreadMessage not found for message ${messageId}`);
+	}
+
+	const written = {
+		category: update.category,
+		...(update.snippet ? { snippet: update.snippet } : {}),
+		...(update.listId ? { listId: update.listId } : {}),
+	};
+
+	for (const row of rows) {
+		if (alreadyDenormalized(row, written)) continue;
+		await deps.threadMessageService.update(
+			accountConfigId,
+			row.threadMessageId,
+			written,
+			{
+				composites: {
+					sentDate: row.sentDate,
+					mailboxId: row.mailboxId,
+					isRead: row.isRead,
+					isDeleted: row.isDeleted,
+					hasStars: row.hasStars,
+					hasAttachment: row.hasAttachment,
+				},
+			},
+		);
+	}
+};