@remit/imap-worker 0.0.62 → 0.0.63

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remit/imap-worker",
-  "version": "0.0.62",
+  "version": "0.0.63",
   "type": "module",
   "main": "dist/index.js",
   "exports": {

package/src/handlers/empty-trash.ts

@@ -15,7 +15,7 @@ import type { EmptyTrashEvent } from "../events.js";
 import { isNotFoundError } from "../is-not-found.js";
 import { withOAuthLifecycle } from "../with-oauth-lifecycle.js";
 import { buildLifecycleDeps } from "../with-oauth-lifecycle-deps.js";
-import { buildThreadMessageUndelete } from "./message-delete.js";
+import { buildThreadMessageUndelete } from "./thread-message-rows.js";
 
 export interface EmptyTrashDeps {
 	getClient: typeof getClient;

package/src/handlers/message-delete-terminal.ts

@@ -1,11 +1,14 @@
-import type { IMessageRepository } from "@remit/data-ports";
-import { MessageStatus, MessageSyncStatus } from "@remit/domain-enums";
+import type {
+	IMessageRepository,
+	IThreadMessageRepository,
+} from "@remit/data-ports";
 import {
 	type IImapConnection,
 	isMessageGoneFromOpenMailbox,
 	reconcileStaleMessage,
 	type StaleMessageReconcileDeps,
 } from "@remit/mailbox-service";
+import { buildThreadMessageMoveRevert } from "./thread-message-rows.js";
 
 export interface MessageDeleteTerminalLogger {
 	info(obj: Record<string, unknown>, msg: string): void;
@@ -14,7 +17,11 @@ export interface MessageDeleteTerminalLogger {
 
 export interface ResolveExhaustedMessageDeleteDeps
 	extends StaleMessageReconcileDeps {
-	messageService: Pick<IMessageRepository, "delete" | "update">;
+	messageService: Pick<IMessageRepository, "delete" | "updateUid">;
+	threadMessageService: Pick<
+		IThreadMessageRepository,
+		"findAllByMessageId" | "deleteMany" | "update"
+	>;
 	log: MessageDeleteTerminalLogger;
 }
 
@@ -22,6 +29,7 @@ export interface ResolveExhaustedMessageDeleteInput {
 	accountId: string;
 	accountConfigId: string;
 	messageId: string;
+	sourceMailboxId: string;
 	uid: number;
 	sourceMailboxPath: string;
 	getConnection: () => Promise<IImapConnection>;
@@ -49,15 +57,18 @@ export interface ResolveExhaustedMessageDeleteResult {
  *    server's own UID. Metric only, no alarm — routine.
  * 2. BROKEN — the message is still at the source, so the delete never took
  *    effect, but it keeps failing: broken code or a broken account, not a
- *    transient blip. The row's mailbox and uid are left exactly as they stand,
- *    because reverting the optimistic move on this ambiguity is what PR #652
- *    was pulled for.
+ *    transient blip. The row is put back where the server has just said the
+ *    message is: `mailboxId` and `uid` return to the delete's source pair, and
+ *    the thread rows lose the deletion mark the optimistic `updateForMove`
+ *    wrote (issue #1098).
  *
- *    `status` does settle, to `active`. It is not a claim about where the
- *    message is — only that this row is no longer mid-mutation. Leaving it
- *    `moving` makes `isPlacementUnsettled` true forever, and every later delete
- *    of that message then waits on a mutation that has already terminated, so
- *    the user is left with mail they cannot delete.
+ *    Settling `status` to `active` while leaving `mailboxId` on Trash is what
+ *    this replaces. `bindsForeignUid` refuses a mismatched pair only while
+ *    `status` is `moving`, so clearing it read as consistent, and the UI then
+ *    offered "Delete permanently" on a Trash mailbox with the source folder's
+ *    uid — an expunge naming a different message. Restoring the pair is not a
+ *    revert on ambiguity (what PR #652 was pulled for): the presence probe
+ *    above has just answered, so this writes a placement the server confirmed.
  *
  * A server that cannot be reached at exhaustion time never reaches either
  * verdict: the probe throws and the record dead-letters with the row untouched.
@@ -71,6 +82,7 @@ export const resolveExhaustedMessageDeleteFailure = async (
 		accountId,
 		accountConfigId,
 		messageId,
+		sourceMailboxId,
 		uid,
 		sourceMailboxPath,
 		getConnection,
@@ -100,10 +112,6 @@ export const resolveExhaustedMessageDeleteFailure = async (
 		return { outcome: "reconciled" };
 	}
 
-	await deps.messageService.update(messageId, {
-		status: MessageStatus.active,
-		syncStatus: MessageSyncStatus.failed,
-	});
 	deps.log.error(
 		{
 			alert: "message_delete_failed",
@@ -111,9 +119,31 @@ export const resolveExhaustedMessageDeleteFailure = async (
 			accountConfigId,
 			messageId,
 			uid,
+			sourceMailboxId,
 			sourceMailboxPath,
 		},
-		"Delete could not be pushed to IMAP after retry exhaustion; the message is still at its source — row settled out of `moving` and left in place for operator investigation",
+		"Delete could not be pushed to IMAP after retry exhaustion; the message is still at its source — row moved back to the source folder",
 	);
+
+	await deps.messageService.updateUid(messageId, uid, sourceMailboxId);
+
+	const threadMessages = await deps.threadMessageService.findAllByMessageId(
+		accountConfigId,
+		messageId,
+	);
+	for (const threadMessage of threadMessages) {
+		const args = buildThreadMessageMoveRevert(
+			threadMessage,
+			uid,
+			sourceMailboxId,
+		);
+		await deps.threadMessageService.update(
+			threadMessage.accountConfigId,
+			threadMessage.threadMessageId,
+			args.set,
+			{ composites: args.composites },
+		);
+	}
+
 	return { outcome: "broken" };
 };

package/src/handlers/message-delete.test.ts

@@ -5,14 +5,16 @@ import type { Logger } from "@remit/logger-lambda";
 import { renderMetrics, resetMetrics } from "@remit/logger-lambda";
 import type { MessageDeleteEvent } from "../events.js";
 import {
-	buildThreadMessageTrashUpdate,
-	buildThreadMessageUndelete,
 	deleteAllThreadMessagesForMessage,
 	getMessageDeleteMaxAttempts,
 	handleMessageDelete,
 	MESSAGE_DELETE_MAX_ATTEMPTS,
 	type MessageDeleteDeps,
 } from "./message-delete.js";
+import {
+	buildThreadMessageTrashUpdate,
+	buildThreadMessageUndelete,
+} from "./thread-message-rows.js";
 
 describe("getMessageDeleteMaxAttempts — env-derived threshold (#980)", () => {
 	it("parses the injected env var", () => {
@@ -676,28 +678,65 @@ describe("handleMessageDelete", () => {
 			);
 		});
 
-		// A source that still holds the uid at the ceiling means the MOVE never
-		// took effect. Local state is left exactly as it stands — the row is the
-		// only record that this delete is still owed, and a revert races a MOVE
-		// that may yet have landed (#652, #655).
-		it("leaves a message still at its source untouched at the ceiling and never re-throws", async () => {
+		// Issue #1098. A source that still holds the uid at the ceiling means the
+		// MOVE never took effect, so the row goes back to the source folder: the
+		// optimistic `updateForMove` left `mailboxId` on Trash while `uid` still
+		// named the source's message, and settling `status` to `active` on top of
+		// that pair switched off every guard that reads `status === "moving"`.
+		// The UI then resolved a Trash `mailboxId` to "Delete permanently", an
+		// expunge of Trash by a uid belonging to a different message. This is not
+		// a revert on ambiguity (#652, #655): the presence probe has just
+		// answered, so the pair written here is the placement the server holds.
+		it("moves a message still at its source back to the source folder at the ceiling", async () => {
 			h.connection.moveMessages = async () => ({ uidMap: new Map() });
 			h.destinationSearchUids = [100];
+			h.allThreadMessages = [
+				{
+					...baseThreadMessage,
+					accountConfigId: "cfg-1",
+					threadMessageId: "tm-1",
+					mailboxId: "trash-mbx",
+					isDeleted: true,
+				},
+			];
 
 			await handleMessageDelete(moveEvent, noopLog, 3, deps());
 
 			assert.equal(called("message.delete").length, 0);
 			assert.equal(called("threadMessage.deleteMany").length, 0);
-			assert.equal(called("threadMessage.update").length, 0);
 
-			// The row's mailbox and uid stay put, but `status` must leave
-			// `moving`: `isPlacementUnsettled` reads exactly that value, so a row
-			// left mid-mutation makes every later delete of this message wait on
-			// a mutation that has already terminated.
-			assert.deepEqual(called("message.update").at(-1)?.args[1], {
-				status: "active",
-				syncStatus: "failed",
-			});
+			// `mailboxId` and `uid` name the same message again, and `updateUid`
+			// settles `status` out of `moving` in the same write, so no later
+			// delete of this message waits on a mutation that has terminated.
+			assert.deepEqual(called("message.updateUid").at(-1)?.args, [
+				"msg-1",
+				10,
+				"src-mbx",
+			]);
+			assert.equal(
+				called("message.update").length,
+				0,
+				"settling `status` without repairing the pair is what left the row addressable as a Trash expunge",
+			);
+
+			// The listing row follows the Message row out of Trash, which is what
+			// makes "Delete permanently" unreachable: the client resolves that
+			// outcome from a target whose `mailboxId` is the Trash mailbox.
+			assert.deepEqual(called("threadMessage.update").at(-1)?.args, [
+				"cfg-1",
+				"tm-1",
+				{ uid: 10, mailboxId: "src-mbx", isDeleted: false },
+				{
+					composites: {
+						sentDate: baseThreadMessage.sentDate,
+						mailboxId: "trash-mbx",
+						isRead: true,
+						isDeleted: true,
+						hasStars: true,
+						hasAttachment: false,
+					},
+				},
+			]);
 			assert.equal(await imapFailures("MESSAGE_DELETE_EXHAUSTED"), 1);
 		});
 
@@ -767,15 +806,16 @@ describe("handleMessageDelete", () => {
 				assert.equal(called("emitEvent").length, 2);
 			});
 
-			it("settles a still-present message at the ceiling out of `moving`", async () => {
+			it("settles a still-present message at the ceiling back onto its source", async () => {
 				moveThrows();
 
 				await handleMessageDelete(moveEvent, noopLog, 3, deps());
 
-				assert.deepEqual(called("message.update").at(-1)?.args[1], {
-					status: "active",
-					syncStatus: "failed",
-				});
+				assert.deepEqual(called("message.updateUid").at(-1)?.args, [
+					"msg-1",
+					10,
+					"src-mbx",
+				]);
 				assert.equal(await imapFailures("MESSAGE_DELETE_EXHAUSTED"), 1);
 			});
 		});

package/src/handlers/message-delete.ts

@@ -2,7 +2,6 @@ import { getClient } from "@remit/backend/client";
 import type {
 	IMessageRepository,
 	IThreadMessageRepository,
-	ThreadMessageItem,
 } from "@remit/data-ports";
 import { isCurrentSchemaVersion } from "@remit/data-ports/mutation-events";
 import { MessageStatus, MessageSyncStatus } from "@remit/domain-enums";
@@ -24,6 +23,10 @@ import { withOAuthLifecycle } from "../with-oauth-lifecycle.js";
 import { buildLifecycleDeps } from "../with-oauth-lifecycle-deps.js";
 import { resolveExhaustedMessageDeleteFailure } from "./message-delete-terminal.js";
 import { emitMoveResync, searchMailboxByMessageId } from "./message-move.js";
+import {
+	buildThreadMessageMoveRevert,
+	buildThreadMessageTrashUpdate,
+} from "./thread-message-rows.js";
 
 /**
  * Fallback when `MESSAGE_DELETE_MAX_ATTEMPTS` is unset (local dev, unit tests).
@@ -73,82 +76,6 @@ export const deleteAllThreadMessagesForMessage = async (
 	return rows.length;
 };
 
-/**
- * Build the `set` and `composites` payload for the ThreadMessage update on a
- * MESSAGE_DELETE move-to-trash.
- *
- * The CURRENT row state goes in `composites`; the NEW values go in `set`.
- * ElectroDB uses `composites` to run the conditional check on the existing row
- * AND to compute the previous sort-key values needed to recompute the new ones.
- * Passing the NEW values in `composites` makes the conditional check fail with
- * ConditionalCheckFailedException, which ElectroDB wraps as NotFoundError, and
- * the caller silently drops the update. Same root cause as PR #186 fixed for
- * `flag-queue.ts`.
- */
-type ThreadMessageRowState = Pick<
-	ThreadMessageItem,
-	| "sentDate"
-	| "mailboxId"
-	| "isRead"
-	| "isDeleted"
-	| "hasStars"
-	| "hasAttachment"
->;
-
-const currentComposites = (threadMessage: ThreadMessageRowState) => ({
-	sentDate: threadMessage.sentDate,
-	mailboxId: threadMessage.mailboxId,
-	isRead: threadMessage.isRead,
-	isDeleted: threadMessage.isDeleted,
-	hasStars: threadMessage.hasStars,
-	hasAttachment: threadMessage.hasAttachment,
-});
-
-export const buildThreadMessageTrashUpdate = (
-	threadMessage: ThreadMessageRowState,
-	newUid: number,
-	destinationMailboxId: string,
-) => ({
-	set: {
-		uid: newUid,
-		mailboxId: destinationMailboxId,
-		isDeleted: true,
-	},
-	composites: currentComposites(threadMessage),
-});
-
-/**
- * The inverse payload: put the thread row back where the message still is on
- * the server. The delete was recorded optimistically, so a delete abandoned
- * before any IMAP write has to hand the row back rather than leave it claiming
- * Trash — an invisible `failed` on a row the user cannot see is the shape of
- * the incident this whole change is about.
- */
-export const buildThreadMessageMoveRevert = (
-	threadMessage: ThreadMessageRowState,
-	sourceUid: number,
-	sourceMailboxId: string,
-) => ({
-	set: {
-		uid: sourceUid,
-		mailboxId: sourceMailboxId,
-		isDeleted: false,
-	},
-	composites: currentComposites(threadMessage),
-});
-
-/**
- * Hand a row back after an abandoned expunge. The mail never left Trash, so
- * only the deletion mark reverts — the uid and mailbox on the row are still
- * where the server has it.
- */
-export const buildThreadMessageUndelete = (
-	threadMessage: ThreadMessageRowState,
-) => ({
-	set: { isDeleted: false },
-	composites: currentComposites(threadMessage),
-});
-
 /**
  * Settle a move to Trash the server left unconfirmed, by asking it two
  * read-only questions instead of one. Both handles wrap the SAME connection but
@@ -349,6 +276,7 @@ export const handleMessageDelete = async (
 				accountId,
 				accountConfigId,
 				messageId,
+				sourceMailboxId: mailboxId,
 				uid,
 				sourceMailboxPath: mailboxPath,
 				getConnection,
@@ -362,11 +290,9 @@ export const handleMessageDelete = async (
 		// Both verdicts end in a row the server has contradicted, so this delete
 		// reconciles rather than waits (R2): whichever folder actually holds the
 		// message re-projects it with the server's own uid. RECONCILED, the local
-		// rows are gone and the resync rebuilds them. BROKEN, the server has just
-		// confirmed the message is still at the source while the optimistic
-		// `updateForMove` left the row pointing at Trash — without the resync the
-		// user sees it in Trash for as long as that row stands, which is the
-		// silent misdirection the settle exists to end.
+		// rows are gone and the resync rebuilds them. BROKEN, the row has just
+		// been put back at the source the server confirmed, and the resync is
+		// what carries any drift either folder has picked up since.
 		if (destinationMailboxId) {
 			await emitMoveResync(emitEvent, {
 				accountId,

package/src/handlers/thread-message-rows.ts

@@ -0,0 +1,77 @@
+import type { ThreadMessageItem } from "@remit/data-ports";
+
+/**
+ * Build the `set` and `composites` payload for the ThreadMessage update on a
+ * MESSAGE_DELETE move-to-trash.
+ *
+ * The CURRENT row state goes in `composites`; the NEW values go in `set`.
+ * ElectroDB uses `composites` to run the conditional check on the existing row
+ * AND to compute the previous sort-key values needed to recompute the new ones.
+ * Passing the NEW values in `composites` makes the conditional check fail with
+ * ConditionalCheckFailedException, which ElectroDB wraps as NotFoundError, and
+ * the caller silently drops the update. Same root cause as PR #186 fixed for
+ * `flag-queue.ts`.
+ */
+export type ThreadMessageRowState = Pick<
+	ThreadMessageItem,
+	| "sentDate"
+	| "mailboxId"
+	| "isRead"
+	| "isDeleted"
+	| "hasStars"
+	| "hasAttachment"
+>;
+
+const currentComposites = (threadMessage: ThreadMessageRowState) => ({
+	sentDate: threadMessage.sentDate,
+	mailboxId: threadMessage.mailboxId,
+	isRead: threadMessage.isRead,
+	isDeleted: threadMessage.isDeleted,
+	hasStars: threadMessage.hasStars,
+	hasAttachment: threadMessage.hasAttachment,
+});
+
+export const buildThreadMessageTrashUpdate = (
+	threadMessage: ThreadMessageRowState,
+	newUid: number,
+	destinationMailboxId: string,
+) => ({
+	set: {
+		uid: newUid,
+		mailboxId: destinationMailboxId,
+		isDeleted: true,
+	},
+	composites: currentComposites(threadMessage),
+});
+
+/**
+ * The inverse payload: put the thread row back where the message still is on
+ * the server. The delete was recorded optimistically, so a delete that gives up
+ * with the message still at its source has to hand the row back rather than
+ * leave it claiming Trash — an invisible `failed` on a row the user cannot see
+ * is the shape of the incident this whole change is about.
+ */
+export const buildThreadMessageMoveRevert = (
+	threadMessage: ThreadMessageRowState,
+	sourceUid: number,
+	sourceMailboxId: string,
+) => ({
+	set: {
+		uid: sourceUid,
+		mailboxId: sourceMailboxId,
+		isDeleted: false,
+	},
+	composites: currentComposites(threadMessage),
+});
+
+/**
+ * Hand a row back after an abandoned expunge. The mail never left Trash, so
+ * only the deletion mark reverts — the uid and mailbox on the row are still
+ * where the server has it.
+ */
+export const buildThreadMessageUndelete = (
+	threadMessage: ThreadMessageRowState,
+) => ({
+	set: { isDeleted: false },
+	composites: currentComposites(threadMessage),
+});