@remit/smtp-worker 0.0.13 → 0.0.15

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remit/smtp-worker",
-  "version": "0.0.13",
+  "version": "0.0.15",
   "type": "module",
   "main": "dist/index.js",
   "exports": {
@@ -30,14 +30,12 @@
     "@remit/mail-oauth-service": "*",
     "@remit/mailbox-service": "*",
     "@aws-sdk/client-sqs": "*",
-    "drizzle-orm": "^0.45.2",
     "expect-env": "*",
     "@types/aws-lambda": "*"
   },
   "devDependencies": {
     "@aws-sdk/core": "*",
     "@remit/storage-service": "*",
-    "@types/pg": "^8.0.0",
     "esbuild": "^0.27.7",
     "p-map": "*"
   },

package/src/data-ports.ts

@@ -5,15 +5,10 @@ import type {
 	IMessageRepository,
 	IOutboxMessageRepository,
 } from "@remit/data-ports";
-// Type-only: erased at build, so it carries no runtime dependency on
-// drizzle-orm. The value import lives inside the relational builders as a
-// dynamic `import()` — see the comment there for why.
-import type { NodePgDatabase } from "drizzle-orm/node-postgres";
 
 /**
- * The repositories the SMTP send path reads and writes. One neutral seam over
- * the three backends (DynamoDB / Postgres / SQLite), selected by
- * `buildDataPortsFromEnv` so the same handler serves every stack.
+ * The repositories the SMTP send path reads and writes. One neutral seam so the
+ * same handler serves every stack.
  */
 export interface SmtpDataPorts {
 	account: IAccountRepository;
@@ -23,48 +18,13 @@ export interface SmtpDataPorts {
 	envelope: IEnvelopeRepository;
 }
 
-// `@remit/drizzle-service` and `drizzle-orm/node-postgres` are loaded
-// lazily, inside these functions, instead of as static top-level imports. The
-// relational branches only ever run when `DATA_BACKEND` selects them — never on
-// the deployed Lambda — but a static import is bundled (and evaluated at module
-// load) regardless of whether its branch runs. Both packages are marked
-// `external` for the Lambda esbuild build (LAMBDA_ESBUILD_OPTIONS), so esbuild
-// leaves this `import()` unresolved in the bundle; it resolves only on the
-// relational path, which runs via `tsx`/the container bundle with both packages
+// `@remit/drizzle-service` is loaded lazily, inside this function, instead of as
+// a static top-level import. A static import is bundled (and evaluated at module
+// load) regardless of whether the branch that uses it ever runs; the package is
+// marked `external` for the Lambda esbuild build (LAMBDA_ESBUILD_OPTIONS), so
+// esbuild leaves this `import()` unresolved in the bundle. It resolves only
+// where the relational composition actually runs, which has the package
 // installed. Mirrors the search-index-worker data-ports seam.
-const buildPostgresDataPorts = async (): Promise<SmtpDataPorts> => {
-	const pgConnectionUrl = process.env.PG_CONNECTION_URL;
-	if (!pgConnectionUrl) throw new Error("PG_CONNECTION_URL is required");
-
-	const {
-		AccountRepo,
-		AddressRepo,
-		DrizzleEnvelopeRepository,
-		DrizzleMessageRepository,
-		messageDataSchema,
-		OutboxMessageRepo,
-	} = await import("@remit/drizzle-service");
-	const { drizzle } = await import("drizzle-orm/node-postgres");
-
-	const db = drizzle(pgConnectionUrl, { schema: messageDataSchema });
-	const genericDb = db as unknown as NodePgDatabase<Record<string, unknown>>;
-	const messageDataDb = db as unknown as NodePgDatabase<
-		typeof messageDataSchema
-	>;
-
-	return {
-		account: new AccountRepo(genericDb),
-		outboxMessage: new OutboxMessageRepo(genericDb),
-		address: new AddressRepo(genericDb),
-		message: new DrizzleMessageRepository(messageDataDb),
-		envelope: new DrizzleEnvelopeRepository(messageDataDb),
-	};
-};
-
-// The SQLite twin of `buildPostgresDataPorts` (RFC 036): the same Drizzle repos
-// over the one shared SQLite file. `createSqliteDatabase` (and better-sqlite3
-// behind it) is kept external from the DynamoDB Lambda bundle by the same
-// dynamic-import treatment.
 const buildSqliteDataPorts = async (): Promise<SmtpDataPorts> => {
 	const sqliteDbPath = process.env.SQLITE_DB_PATH;
 	if (!sqliteDbPath) throw new Error("SQLITE_DB_PATH is required");
@@ -82,17 +42,13 @@ const buildSqliteDataPorts = async (): Promise<SmtpDataPorts> => {
 	const { db } = await createSqliteDatabase(messageDataSchema, {
 		filename: sqliteDbPath,
 	});
-	const genericDb = db as unknown as NodePgDatabase<Record<string, unknown>>;
-	const messageDataDb = db as unknown as NodePgDatabase<
-		typeof messageDataSchema
-	>;
 
 	return {
-		account: new AccountRepo(genericDb),
-		outboxMessage: new OutboxMessageRepo(genericDb),
-		address: new AddressRepo(genericDb),
-		message: new DrizzleMessageRepository(messageDataDb),
-		envelope: new DrizzleEnvelopeRepository(messageDataDb),
+		account: new AccountRepo(db),
+		outboxMessage: new OutboxMessageRepo(db),
+		address: new AddressRepo(db),
+		message: new DrizzleMessageRepository(db),
+		envelope: new DrizzleEnvelopeRepository(db),
 	};
 };
 
@@ -101,28 +57,23 @@ let injectedDataPorts: SmtpDataPorts | null = null;
 /**
  * Register the DynamoDB-backed SMTP data ports from the composition root. The
  * DynamoDB composition lives outside this shared, open-core module and is never
- * imported here. The relational backends compose in-package below and never
- * touch this seam.
+ * imported here. The relational backend composes in-package above and never
+ * touches this seam.
  */
 export const setSmtpDataPorts = (ports: SmtpDataPorts): void => {
 	injectedDataPorts = ports;
 };
 
 /**
- * Select the SMTP data ports from the environment, mirroring the other workers'
- * `DATA_BACKEND` selection:
- *
- * - `DATA_BACKEND=postgres` → Drizzle repos over `PG_CONNECTION_URL`.
- * - `DATA_BACKEND=sqlite` → Drizzle repos over the shared `SQLITE_DB_PATH` file.
- * - otherwise → the DynamoDB ElectroDB ports the composition root injected.
+ * The SMTP data ports for this process: the ones a composition root registered,
+ * or — for a process that registered none — the SQLite composition this build
+ * contains. `SQLITE_DB_PATH` is that composition's precondition, not a backend
+ * selection.
  */
 export const buildDataPortsFromEnv = async (): Promise<SmtpDataPorts> => {
-	if (process.env.DATA_BACKEND === "postgres") return buildPostgresDataPorts();
-	if (process.env.DATA_BACKEND === "sqlite") return buildSqliteDataPorts();
-	if (!injectedDataPorts) {
-		throw new Error(
-			"no DynamoDB SMTP data ports registered — register them with setSmtpDataPorts() from your composition root",
-		);
-	}
-	return injectedDataPorts;
+	if (injectedDataPorts) return injectedDataPorts;
+	if (process.env.SQLITE_DB_PATH) return buildSqliteDataPorts();
+	throw new Error(
+		"no SMTP data ports registered — register them with setSmtpDataPorts() from your composition root",
+	);
 };

package/src/e2e-processor-shim.ts

@@ -1,4 +1,5 @@
 #!/usr/bin/env node
+import { randomUUID } from "node:crypto";
 import {
 	DeleteMessageCommand,
 	ReceiveMessageCommand,
@@ -46,11 +47,16 @@ process.on("SIGTERM", () => {
 	isShuttingDown = true;
 });
 
-// Minimal Lambda Context: `withTelemetry` only reads `functionName`, for the
-// line it logs per invocation; the prod handler never touches the rest.
-const lambdaContext = {
-	functionName: `e2e-smtp-worker-${queueName}`,
-} as Context;
+// Minimal Lambda Context: `withTelemetry` reads `functionName` for the line it
+// logs per invocation and `awsRequestId` for the scope it opens around it, so
+// every line one batch produces shares a `requestId` (deploy/vps/README.md,
+// "Logs"). Minted per batch, like the production poller does — a context built
+// once would put the whole run under one id, which correlates nothing.
+const nextContext = (): Context =>
+	({
+		functionName: `e2e-smtp-worker-${queueName}`,
+		awsRequestId: randomUUID(),
+	}) as Context;
 
 const pollQueue = async (): Promise<void> => {
 	log.info("Worker started, polling...", { maxMessages });
@@ -115,7 +121,7 @@ const pollQueue = async (): Promise<void> => {
 			})),
 		};
 
-		const result = (await handler(event, lambdaContext)) as
+		const result = (await handler(event, nextContext())) as
 			| SQSBatchResponse
 			| undefined;