Repository navigation
test(nextly): the outbox lock suite registers its seeded collection, as a builder save does - #1813
Conversation
…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].
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Warning Review limit reachedNext included review available in 53 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@codex review |
|
Codex Review: Didn't find any major issues. Keep it up! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
@nextlyhq/adapter-drizzle
@nextlyhq/adapter-mysql
@nextlyhq/adapter-postgres
@nextlyhq/adapter-sqlite
@nextlyhq/admin
@nextlyhq/admin-css
@nextlyhq/blocks-engine
@nextlyhq/blocks-react
@nextlyhq/builder
create-nextly-app
@nextlyhq/eslint-plugin
nextly
@nextlyhq/plugin-form-builder
@nextlyhq/plugin-page-builder
@nextlyhq/plugin-sdk
@nextlyhq/plugin-seo
@nextlyhq/storage-s3
@nextlyhq/storage-uploadthing
@nextlyhq/storage-vercel-blob
@nextlyhq/ui
commit: |
|
|
1 participant
What
Repairs
main's Integration (postgres) and Integration (mysql), both failing atoutbox-preimage-lock.integration.test.ts› serializes concurrent updates so neither event claims the other's field withexpected [] to have a length of 2.Ledger:
finding:outbox-lock-suite-never-registered-its-collection.What was true
The suite boots once, seeds its collection straight into the database with
seedBuilderCollection, and writes through the handler. Both updates answer 500 —Table "dc_locktestposts" not found in schema registry, so noentry.updatedevent is written and the assertion sees none. The suite never asserts the updates' own results, so the failure presented as a missing event rather than a refused write.Saving a collection in the Builder registers its new table with the schema resolver as part of the save (
collection-metadata-servicecallsregisterDynamicSchema). Seeding into the database does not, andseed-builder-entity's own docblock says to boot again afterwards — which the other two-phase suites (collection-mutation-service.m2m-atomicity,write-path-relations-tx-visibility, …) do and this one did not. Reads were unaffected because the read path builds its own runtime table; the ORM write path had nothing to resolve.It surfaced now for two reasons: the legs are dialect-gated, so only pg/mysql run it, and my #1787 moved the transactional update onto the resolver — the raw statement it replaced quoted the table name itself, so an unregistered table had gone unnoticed here. The adapter's transactional delete has always required the resolver, so the same suite would have failed had it deleted.
How
After seeding,
clearServices()and boot again over the same adapter — the documented pattern, three lines.Verification
Integration (postgres)and(mysql)are the oracle — read them by name on this head. No Docker here.git statusclean): without the second boot both updates answer that 500,nextly_eventsholds onlyentry.created, andgetEntry/listEntriesstill succeed — the asymmetry above, measured. With it, both updates succeed and exactly twoentry.updatedevents appear,changedFields["alpha","updatedAt"]and["beta","updatedAt"]— which also satisfies the property the suite exists for (neither event carries the other's field).No changeset: test-only.