@porulle/core 0.36.0 → 0.38.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@porulle/core",
-  "version": "0.36.0",
+  "version": "0.38.0",
   "license": "MIT",
   "type": "module",
   "exports": {
@@ -62,8 +62,8 @@
     "eslint": "^9.39.1",
     "typescript": "5.9.2",
     "vitest": "^3.2.4",
-    "@porulle/eslint-config": "0.1.0",
-    "@porulle/typescript-config": "0.1.0"
+    "@porulle/typescript-config": "0.1.0",
+    "@porulle/eslint-config": "0.1.0"
   },
   "publishConfig": {
     "access": "public"

package/src/kernel/hooks/executor.ts

@@ -1,4 +1,5 @@
 import type { AfterHook, BeforeHook, HookContext, HookOperation } from "./types.js";
+import type { PluginDb } from "../database/plugin-types.js";
 import { deferAfterCommit } from "./deferred.js";
 import { reportHookFailure } from "./failures.js";
 
@@ -19,6 +20,29 @@ export function mergeHookReports(a: HookReport, b: HookReport): HookReport {
   };
 }
 
+/**
+ * The context a hook marked `inTransaction: true` receives.
+ *
+ * `inTransaction` buys ORDERING on its own — the hook runs inline, before the commit. It does not
+ * make the hook's WRITES part of the transaction: `context.db` is the plugin db handle, and on a
+ * two-connection driver (Neon over HTTP, where every plain query is its own request) a write on
+ * that handle is not in the transaction and survives its rollback. Measured on the deployed Worker
+ * on 2026-09-15: an aborted write left `entity_exists = 0` and `pending_for_aborted = 1` — a row
+ * that rolled back announcing itself in the outbox whose entire purpose is committing with it.
+ *
+ * So the kernel hands such a hook a context it cannot get this wrong from: `db` IS the transaction.
+ * A plugin author writing the obvious thing lands inside the transaction, with nothing to remember.
+ *
+ * `tx` can still be null here — a marked hook also fires for a write performed outside any
+ * transaction, and `catalogHookContext` passes `tx: null` for one. Such a hook keeps the outside
+ * connection, because that is the only connection there is; handing it nothing would silently stop
+ * every non-transactional write from announcing itself, which is worse than the defect above.
+ */
+function inTransactionHookContext(context: HookContext): HookContext {
+  if (context.tx == null) return context;
+  return { ...context, db: context.tx as PluginDb };
+}
+
 /** Default hook timeout: 20 seconds */
 const HOOK_TIMEOUT_MS = 20_000;
 
@@ -98,7 +122,7 @@ export async function runAfterHooks<T>(
           result: committedResult,
           operation,
           context: runsInTransaction(hook)
-            ? context
+            ? inTransactionHookContext(context)
             : { ...context, tx: null },
         }),
         HOOK_TIMEOUT_MS,

package/src/modules/media/schema.ts

@@ -31,6 +31,14 @@ export const mediaAssets = pgTable(
   },
   (table) => ({
     orgIdx: index("idx_media_assets_org").on(table.organizationId),
+    orgChannelImageUrlHashIdx: index("idx_media_assets_org_channel_image_url_hash").on(
+      table.organizationId,
+      sql`(${table.metadata}->>'channelImageUrlHash')`,
+    ),
+    orgChannelImageExternalIdIdx: index("idx_media_assets_org_channel_image_external_id").on(
+      table.organizationId,
+      sql`(${table.metadata}->>'channelImageExternalId')`,
+    ),
   }),
 );
 

package/src/test-utils/create-two-connection-adapter.ts

@@ -0,0 +1,55 @@
+/**
+ * A test adapter whose transaction handle and `db` handle are two DIFFERENT connections.
+ *
+ * Every other test adapter in this repo is one PGlite instance, which hands the transaction body
+ * the SAME `db` handle it hands everyone else. That makes a whole class of defect invisible by
+ * construction: a write issued on the `db` handle while a transaction is open rides that open
+ * transaction, so it commits and rolls back with it, and a test asserting "the write rolled back"
+ * passes whether or not the code under test routed the write through `tx` at all.
+ *
+ * On the driver this project actually deploys — Neon over HTTP — every plain query on the `db`
+ * handle is its own request on its own connection. Such a write does NOT join the open transaction
+ * and SURVIVES its rollback. Measured on the deployed Worker, 2026-09-15:
+ *
+ *     POST /api/loom/_proof/abort-after-hook
+ *     committed: false   entity_exists = 0   pending_for_aborted = 1
+ *
+ * This adapter reproduces that property with two PGlite instances: transactions run on one, the
+ * `db` handle is the other. The two do not share data, which a real two-connection driver would —
+ * that is the one way it is unlike Neon, and it is why the assertions below name WHICH connection
+ * a row landed on rather than reading either one alone.
+ */
+
+import type { DatabaseAdapter } from "../kernel/database/adapter.js";
+import type { DrizzleDatabase } from "../kernel/database/drizzle-db.js";
+import { createPGliteTestAdapter } from "./create-pglite-adapter.js";
+
+export interface TwoConnectionTestAdapter {
+  adapter: DatabaseAdapter;
+  /** The connection `adapter.transaction` opens its transaction on. */
+  txDb: DrizzleDatabase;
+  /** The connection `adapter.db` points at — the "outside" connection. */
+  outsideDb: DrizzleDatabase;
+  cleanup: () => Promise<void>;
+}
+
+export async function createTwoConnectionTestAdapter(): Promise<TwoConnectionTestAdapter> {
+  const transactional = await createPGliteTestAdapter();
+  const outside = await createPGliteTestAdapter();
+
+  const adapter: DatabaseAdapter = {
+    provider: "postgresql",
+    db: outside.db,
+    transaction: transactional.adapter.transaction,
+  };
+
+  return {
+    adapter,
+    txDb: transactional.db,
+    outsideDb: outside.db,
+    cleanup: async () => {
+      await transactional.cleanup();
+      await outside.cleanup();
+    },
+  };
+}