From f61183826e9d8916decaa95ad079bc17ce096b95 Mon Sep 17 00:00:00 2001 From: Mobeen Abdullah Date: Sat, 12 Sep 2026 01:48:59 +0300 Subject: [PATCH] test(nextly): the outbox lock suite registers its seeded collection, as a builder save does main's Integration (postgres) and (mysql) fail here: both updates answer 500, 'Table "dc_locktestposts" not found in schema registry', so no entry.updated event is written and the assertion sees none. The suite never asserted the updates' own results, so the cause read as a missing event. The collection is seeded straight into the database, and only a Builder save registers a new table with the schema resolver (collection-metadata-service does it as it saves). Reads build their own table and worked; the ORM write path had nothing to resolve. Booting again over the same adapter after seeding is what seed-builder-entity documents and what the other two-phase suites do. Visible only on those legs because the suite is dialect-gated, and it surfaced now because #1787 moved the transactional update onto the resolver - the raw statement it replaced quoted the table name itself. Verified on SQLite through the same sequence in a scratch probe: without the second boot both updates answer that 500 and no entry.updated is recorded; with it, both succeed and exactly two events appear, changedFields [alpha, updatedAt] and [beta, updatedAt]. --- .../__tests__/outbox-preimage-lock.integration.test.ts | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/packages/nextly/src/domains/webhooks/__tests__/outbox-preimage-lock.integration.test.ts b/packages/nextly/src/domains/webhooks/__tests__/outbox-preimage-lock.integration.test.ts index bc645b6b77..8692b59e6c 100644 --- a/packages/nextly/src/domains/webhooks/__tests__/outbox-preimage-lock.integration.test.ts +++ b/packages/nextly/src/domains/webhooks/__tests__/outbox-preimage-lock.integration.test.ts @@ -15,6 +15,7 @@ import { afterAll, beforeAll, describe, expect, it } from "vitest"; import { createAdapter } from "../../../database/factory"; +import { clearServices } from "../../../di/register"; import { seedBuilderCollection } from "../../../plugins/__tests__/seed-builder-entity"; import { createTestNextly, @@ -114,6 +115,13 @@ for (const leg of LEGS) { { name: "beta", type: "text" }, ], }); + // Then boot again over the same adapter, which is what the seed helper + // documents and what the other two-phase suites do. Saving a + // collection in the Builder registers its table with the schema + // resolver as part of the save; seeding straight into the database + // does not, and a write through the ORM has no table to resolve. + clearServices(); + handle = await createTestNextly({ adapter: bootAdapter }); const h = handle.getService("collectionsHandler"); const created = await h.createEntry(