[plugin-multi-tenant] Race condition in auto-injected relationship field validation produces false "invalid relationship" errors #16462

Activity

1. amitzur

   added

   status: needs-triagePossible bug which hasn't been reproduced yetPossible bug which hasn't been reproduced yet

   validate-reproductionAuto-added tag on create to tell bot to check recreation URL, removed after check.Auto-added tag on create to tell bot to check recreation URL, removed after check.

   v3

   on May 4, 2026
2. github-actions

   added

   db: mongodb@payloadcms/db-mongodb@payloadcms/db-mongodb

   plugin: multi-tenant@payloadcms/plugin-multi-tenant@payloadcms/plugin-multi-tenant

   and removed

   validate-reproductionAuto-added tag on create to tell bot to check recreation URL, removed after check.Auto-added tag on create to tell bot to check recreation URL, removed after check.

   on May 4, 2026
3. github-actions

   added

   stale

   on Jun 7, 2026
4. remiroyc commented on Sep 30, 2026

   

   remiroyc

   on Sep 30, 2026

   More actions

   We hit this in production without plugin-multi-tenant, so the race looks like a core / db-mongodb issue rather than a plugin one.

   Setup

   • payload 3.88.0, @payloadcms/db-mongodb 3.88.0, MongoDB Atlas (replica set)
   • A collection with a blocks field. Several blocks contain a plain upload field with a static filterOptions (a mime type filter):

   {
     name: 'video',
     type: 'upload',
     relationTo: 'blog-media',
     filterOptions: { mimeType: { in: ['video/mp4', 'video/quicktime'] } },
   }

   What happens

   Creating a document with two or more of these fields and publishing it in the same request (POST /api/posts, no draft) intermittently fails with The following fields are invalid: … Video. The referenced uploads exist and match the filter. The server logs one Error validating filter options for collection blog-media per failed field, with:

   MongoServerError: Given transaction number 1 does not match any in-progress transactions. The active transaction number is -1
   

   (NoSuchTransaction, code 251), and on later attempts Transaction … has been aborted.

   Only create is affected. Saving as a draft first and then publishing always works, which fits the analysis above: updateByID reads the existing document on the session before validating, so the transaction already exists on the server when the concurrent validateFilterOptions finds start. On create, those finds are the first commands on the session.

   Reproduction

   With our config against a local single-node replica set, creating a document with 6 such upload blocks and draft: false failed in 6 of 15 runs with the same error.

   Workaround

   A collection beforeOperation hook that awaits one read on the request's session before validation. With it, 0 of 8 runs failed in the same repro:

   const openTransactionBeforeCreate: CollectionBeforeOperationHook = async ({ args, collection, operation, req }) => {
     if (operation !== 'create' || !req.transactionID) return args
     await req.payload.db.findOne({ collection: collection.slug, req, select: { id: true }, where: {} })
     return args
   }

   This only makes sure the transaction is started before the parallel finds; the finds still run concurrently on the session afterwards. Serializing them as in #16463 looks like the proper fix, and it would cover our case too since it isn't specific to the multi-tenant plugin.
5. github-actions

   removed

   stale

   on Oct 4, 2026