Cannot publish entry when Meilisearch is enabled

[douwepausma]

Description
Cannot publish entry when Meilisearch is enabled for that collection.

Expected behavior
Publishing my entry.

Current behavior
Publish results in a "Warning: Internal Server Error". Console gives me the following:

Undefined binding(s) detected when compiling UPDATE. Undefined column(s): [project_id] query: update "projects_articles_lnk" set "project_ord" = ? where "project_id" = ? and "article_id" = ?

Environment:

• OS: Both Mac and Ubuntu
• Meilisearch version: 1.13.2
• strapi-plugin-meilisearch version: 0.13.3
• Browser: Arc Version 1.108.0
• Strapi version: 5.22.0

[BIhab]

Same issue on my side, on Strapi 5.23.1, to reproducte:

• index a collection in meilosearch per example: products
• try to update an entry of that collection, per example: try to modify the name of an indexed product
• click on publish

This will fire the error.

[Strift]

Hello, the team has little bandwidth at the time to handle this, but we would be happy to help with reviewing a PR 🙏

[quinnlangille]

@douwepausma getting the same issue, and found that first unpublishing before hitting publish gets around it. Assuming that narrows it down to something with the content draft system in v5, but haven't looked any deeper

[BIhab]

I want to add more details, I tried on the playground with Strapi v5.9.0, the issue doesn't occur, but when I changed the version to v5.23.3, the problem occured, I tried with different version 5.20.0, 5.16.0 ... and the problem is there, I'm trying to find the exact version where the problem start showing, and check the changelog to find what change(s) made the issue to rise.

[BIhab]

I want to add more details, I tried on the playground with Strapi v5.9.0, the issue doesn't occur, but when I changed the version to v5.23.3, the problem occured, I tried with different version 5.20.0, 5.16.0 ... and the problem is there, I'm trying to find the exact version where the problem start showing, and check the changelog to find what change(s) made the issue to rise.

I found two workarounds to quickly avoid the issue:

1. Downgrade to Strapi V5.10.4 ( the problem occurs starting from version 5.11.0, probably something related to Strapi internal code )
   Or:
2. Disable Draft & Publish

Neither of these solutions is a real fix, especially if we want to benefit from new Strapi updates and fixes, but let stick with this until we found a way to fix it.

[creativdex]

Issue Description

The problem occurs due to the republication mechanism in newer Strapi versions, which utilizes manyToMany relations.

Various methods are responsible for implementing this mechanism.

The core issue is related to Strapi's lifecycle events timing.

The Meilisearch plugin activates after the afterUpdate event, which fires after an entity is updated during the publication process.

However, republication is not yet complete when the plugin activates, and subsequently, bidirectional relation synchronization occurs, leading to conflicts and transaction errors.

For analysis of this process, refer to the createContentTypeRepository.publish() method in @strapi/core/dist/services/document-service/repository.js.

Solution

I resolved this issue by suppressing the default plugin lifecycle handling via Monkey Patching and implementing an alternative mechanism through Document Service Middleware within Strapi core, rather than within the plugin itself.

This approach allows binding to the publication completion moment (after bidirectional relation synchronization) rather than to the entity update moment, ensuring all database operations are fully completed before Meilisearch indexing occurs.

Technical Details

1. Root Cause: Meilisearch lifecycle events (afterCreate/afterUpdate) execute during active database transactions, before bidirectional relation sync completes
2. Conflict: When relations are synchronized later, it conflicts with ongoing Meilisearch operations, causing Transaction query already complete errors
3. Fix: Document Service Middleware executes after all database operations (including relation sync) are finished, using fresh queries in new transactions

This solution ensures proper execution order: Entity Creation → Relation Synchronization → Meilisearch Indexing.

// src/index.ts

  register({ strapi }) {
    // Intercept lifecycle subscriptions to disable Meilisearch ones
    const originalSubscribe = strapi.db.lifecycles.subscribe;
    strapi.db.lifecycles.subscribe = function (options) {
      // Check if this is a Meilisearch subscription by checking the call stack
      const stack = new Error().stack;
      const isMeilisearchSubscription =
        stack && stack.includes("strapi-plugin-meilisearch");

      if (isMeilisearchSubscription) {
        strapi.log.debug("Blocking Meilisearch lifecycle subscription", {
          models: options.models,
        });
        // Return empty object to disable the subscription
        return {};
      }

      // Allow other subscriptions to proceed normally
      return originalSubscribe.call(this, options);
    };

    // Get content types that should be indexed by Meilisearch
    const meilisearchPlugin = strapi.plugin("meilisearch");
    const trackedContentTypes = meilisearchPlugin?.config?.contentTypes || [];

    // Document Service middleware for Meilisearch indexing AFTER all relations are synced
    strapi.documents.use(async (ctx, next) => {
      // Only apply to tracked content types and create/update actions
      if (
        !trackedContentTypes.includes(ctx.uid) ||
        !["create", "update", "publish"].includes(ctx.action)
      ) {
        return next();
      }

      strapi.log.debug("Document middleware: processing content", {
        uid: ctx.uid,
        action: ctx.action,
      });

      // Execute the Document Service method (includes bidirectional sync)
      const result = await next();

      // AFTER: relations are now synchronized, safe to index in Meilisearch
      strapi.log.debug("Document middleware: relations synchronized", {
        uid: ctx.uid,
        action: ctx.action,
        resultId: result?.id,
      });

      try {
        // Get fresh document with all relations populated
        const fresh = await strapi.documents(ctx.uid).findOne({
          documentId: result.documentId,
          populate: "*", // or specify needed relations
          status: result.publishedAt ? "published" : "draft",
        });

        if (fresh) {
          const meilisearch = strapi
            .plugin("meilisearch")
            .service("meilisearch");

          if (
            ctx.action === "create" ||
            (ctx.action === "publish" && !result.publishedAt)
          ) {
            await meilisearch.addEntriesToMeilisearch({
              contentType: ctx.uid,
              entries: [fresh],
            });
          } else {
            await meilisearch.updateEntriesInMeilisearch({
              contentType: ctx.uid,
              entries: [fresh],
            });
          }

          strapi.log.info("Meilisearch: content successfully indexed", {
            contentType: ctx.uid,
            action: ctx.action,
            documentId: fresh.documentId,
          });
        }
      } catch (error) {
        strapi.log.error("Meilisearch: indexing failed", {
          contentType: ctx.uid,
          action: ctx.action,
          error: error.message,
        });
      }

      return result;
    });
  },

[quinnlangille]

@creativdex this seems to make sense re: behaviour I'm seeing as well. A few users of my strapi instance have reported "random" issues when saving documents that are indexed into meilisearch. Specifically, content blocks with images attached shuffle around when reordered, which I'm assuming is to do with the race-condition-y behaviour you're describing around the db transactions

I'll test your snippet above today and see if it also resolves on my end

[quinnlangille]

@creativdex your patch fixes the publish issue, really nice find. Will take me a bit to test if there's any impact to meilisearch indexing, but looking quickly seems like all is working as expected there