@remit/imap-worker 0.0.31 → 0.0.33

package/package.json

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

package/src/handlers/mailbox-management.test.ts

@@ -106,6 +106,10 @@ const deps = (): MailboxManagementDeps =>
 					h.calls.push({ method: "mailbox.update", args });
 					if (h.mailboxUpdateError) throw h.mailboxUpdateError;
 				},
+				findByPathPrefix: async (...args: unknown[]) => {
+					h.calls.push({ method: "mailbox.findByPathPrefix", args });
+					return [];
+				},
 				delete: record("mailbox.delete"),
 			},
 			secrets: {},

package/src/handlers/mailbox-management.ts

@@ -70,15 +70,18 @@ const isMailboxPresentUpstream = (error: unknown): boolean => {
  * Pinned invariant for the whole-chain terminal guards below.
  *
  * Each handler wraps its `MailboxManagementService.sync*` chain in a try/catch
- * that treats a NotFoundError as terminal (ack with a WARN, issue #289). That
- * is only sound because `syncCreate` / `syncRename` / `syncDelete` — and their
- * error-recovery branches here — touch nothing but the single target mailbox
- * row via `mailboxService.get/update/delete(accountId, mailboxId)`. So the only
- * row a NotFoundError can refer to is that target, and its absence can only mean
- * the user deleted the folder mid-sync — never an unrelated missing entity that
- * should have been retried. If a sync method ever reads or writes a second
- * entity, narrow these catches (match the mailboxId / re-check existence) before
- * a NotFoundError from elsewhere is silently acked.
+ * that treats a NotFoundError as terminal (ack with a WARN, issue #289). That is
+ * only sound while the sole row a NotFoundError can refer to is the target
+ * mailbox, so its absence can only mean the user deleted the folder mid-sync —
+ * never an unrelated missing entity that should have been retried.
+ *
+ * `syncCreate` and `syncDelete` hold to that by touching nothing but the target
+ * row. `syncRename` also writes the renamed subtree's descendant rows, and keeps
+ * the invariant by absorbing their NotFoundErrors itself: a descendant deleted
+ * mid-settle never reaches these catches. Any sync method that reads or writes a
+ * second entity owes the same, or these catches must be narrowed (match the
+ * mailboxId / re-check existence) before a NotFoundError from elsewhere is
+ * silently acked.
  */
 
 /**

package/src/scheduler/config.ts

@@ -6,15 +6,20 @@
  * in remit-account-worker/src/config.ts).
  *
  * `tickIntervalSeconds` drives how often the tick itself runs — the
- * EventBridge schedule rate in prod, the local-runner loop delay in dev — and
- * must stay well below `offlineIntervalSeconds` so a tick reliably observes
- * every account crossing the threshold. CDK and this runtime default must
- * agree — see infra/lib/config.ts's `mailboxSync` stage config.
+ * EventBridge schedule rate on a managed deployment, the runner's loop delay
+ * everywhere else — and must stay well below `offlineIntervalSeconds` so a tick
+ * reliably observes every account crossing the threshold. CDK and this runtime
+ * default must agree — see infra/lib/config.ts's `mailboxSync` stage config.
  *
  * `offlineIntervalSeconds` is the only due-ness threshold: an account is due
  * once its last successful sync is older than this interval. There is no
  * "online" tier — client-side polling (useStaleAccountSync) covers an
  * account while its mail is actively open in the web client.
+ *
+ * The defaults below are a floor for a deployment that sets neither. The
+ * standalone stack sets both, at a cadence sized for one box and a handful of
+ * accounts, and the checker's stall threshold is derived from those values —
+ * see deploy/vps/docker-compose.sqlite.yml's `scheduler` service.
  */
 
 const DEFAULT_TICK_INTERVAL_SECONDS = 60 * 60; // 1 hour

package/src/scheduler/handler.ts

@@ -16,8 +16,8 @@ const sqsClient = createQueueProducer({ queueUrl: mailboxesQueueUrl });
  * (#1247, restructured #1251). Ticks at `MAILBOX_SYNC_TICK_INTERVAL_SECONDS`
  * (rate schedule, wired in infra/stacks/dev/stacks/remit-worker-stack.ts) and
  * delegates the actual decision + enqueue to `runSchedulerTick` — the same
- * function the local dev-stack timer loop calls (see `local-runner.ts`), so
- * production and local dev run one code path.
+ * function the timer loop calls on a deployment with no EventBridge (see
+ * `runner.ts`), so every deployment runs one code path.
  *
  * Uses the EventBridge event's own `time` (the scheduled fire time) as the
  * tick's `now`, rather than `Date.now()` at processing time. This is what

package/src/scheduler/{local-runner.ts → runner.ts}

@@ -8,18 +8,15 @@ import { getOfflineIntervalMs, getTickIntervalMs } from "./config.js";
 import { runSchedulerTick } from "./run-tick.js";
 
 /**
- * Standalone scheduled-sync runner for the local pg-dev docker-compose stack
- * (#1247, restructured #1251). Production ticks `runSchedulerTick` off an
- * EventBridge schedule (see handler.ts); ElasticMQ/the pg-dev stack has no
- * EventBridge, so this process ticks on a plain loop at the same
- * `MAILBOX_SYNC_TICK_INTERVAL_SECONDS` cadence instead — same function, same
- * config knobs, so local dev behaves like production rather than needing its
- * own scheduling logic.
+ * The scheduled-sync runner for every deployment that has no EventBridge: the
+ * self-host stack's `scheduler` service and the local dev compose stack. A
+ * managed deployment fires `runSchedulerTick` off an EventBridge schedule (see
+ * handler.ts); this process ticks the same function on a plain loop at the same
+ * `MAILBOX_SYNC_TICK_INTERVAL_SECONDS` cadence, so there is one scheduling
+ * implementation and one set of knobs.
  *
- * This is a dev-only harness, not production code: like
- * `e2e-processor-shim.ts`, a tick failure crashes the process loudly rather
- * than swallowing it — docker-compose's `restart: unless-stopped` brings it
- * back for the next tick.
+ * A tick failure crashes the process loudly rather than being swallowed —
+ * compose's `restart: unless-stopped` brings it back for the next tick.
  */
 
 const log = createLogger();
@@ -40,7 +37,7 @@ const CRASH_BACKOFF_MS = 5_000;
 
 log.info(
 	{ tickIntervalMs, offlineIntervalMs },
-	"Local scheduled-sync runner started",
+	"Scheduled-sync runner started",
 );
 
 const runLoop = async (): Promise<void> => {