[SOLVED] Operations on large content fail with MongoDB error

Bugs Solved Bugs
1

I have…

  • [x] Checked the logs and have uploaded a log file and provided a link because I found something suspicious there. Please do not post the log file in the topic because very often something important is missing.

I’m submitting a…

  • [ ] Regression (a behavior that stopped working in a new release)
  • [x] Bug report
  • [ ] Performance issue
  • [ ] Documentation issue or request

Current behavior

Most operations on a large content item (~10k lines when viewed in Inspect > Flat Data view) fail with MongoDB error (detailed error attached):

Command update failed: Only servers in a sharded cluster can start a new transaction at the active transaction number.

This sometimes happens when trying to create the content (attached detailed error error-during-create.json) and always happens when trying to change the status (e.g. moving from Draft to Published) (attached detailed error error-during-change-status.json). Restarting the Squidex instance sometimes help.

Expected behavior

I am able to operate on large content.

Minimal reproduction of the problem

  1. Create attached schema schema.json.
  2. Insert content-small.json content into the schema. Publish it. See it working.
  3. Insert content-large.json content into the schema. It should fail with the error described here.
  4. If large content creation worked, try to publish it. It should fail with the error described here.

You can see these steps done in the attached video reproduction-steps.mp4.

Environment

  • [x] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [ ] Cloud version

Version: 7.0.3

Browser:

  • [x] Chrome (desktop)
  • [ ] Chrome (Android)
  • [ ] Chrome (iOS)
  • [ ] Firefox
  • [ ] Safari (desktop)
  • [ ] Safari (iOS)
  • [ ] IE
  • [ ] Edge

Others:

  • This has only started since upgrading to v7. No such errors where observed on v6 (6.8.0).
  • New v7 config in our Squidex:
STORE__MONGODB__VALUEREPRESENTATION=Document
CONTENTS__OPTIMIZEFORSELFHOSTING=true
CLUSTERING__WORKER=false

There’s a separate instance with CLUSTERING__WORKER=true. Errors described here occur in the instance with CLUSTERING__WORKER=false.

Errors described here happen even if CONTENTS__OPTIMIZEFORSELFHOSTING=false or when STORE__MONGODB__VALUEREPRESENTATION=String or STORE__MONGODB__VALUEREPRESENTATION=Binary.

  • Our MongoDB server is an Atlas M10 cluster (Replica Set - 3 nodes).
  • This is really the only thing I could find when Googling “Only servers in a sharded cluster can start a new transaction at the active transaction number.”.
2

Thanks, I have also found this: https://stackoverflow.com/questions/70756534/mongodb-c-sharp-driver-transaction-fails-in-mongo-atlas

I am going to provide a solution today that you can test.

3

I have a docker tag dev-7133 to be tested.

4

Works like a dream! Thank you for such a quick turnaround.

One slightly odd thing I did notice in the logs…

Disregard the actual message of this warning and look at the reported version of the app - 5.0.0.0. I would expect dev-7133 or 7.0.3.0. Should this be any cause for concern?

{
  "logLevel": "Warning",
  "message": "Authenticated user has no permission to access the app 2328d35d-af80-4d3b-b159-db7bc5bcc2a1 with ID gr.",
  "name": "2328d35d-af80-4d3b-b159-db7bc5bcc2a1",
  "timestamp": "2022-08-26T07:29:27Z",
  "app": {
    "name": "Squidex",
    "version": "5.0.0.0",
    "sessionId": "cdebe9f9-b6e5-4952-a818-5d0e3f07ee39"
  },
  "web": {
    "requestId": "00-70b49eb3fe8adfd16107763f19b71b60-f27a356fddb50529-01",
    "requestPath": "/api/content/gr/knowledge",
    "requestMethod": "GET",
    "routeValues": {
      "area": "api",
      "action": "GetContents",
      "controller": "Contents"
    }
  },
  "category": "Squidex.Web.Pipeline.AppResolver"
}
5

No, I have forgotten to set the default version in the dockerfile. It is overwritten with actual versions, but only for release builds.

6

Roger that!

Do you plan to release this fix today?

7

I will have a look, but you can safely use the docker tag above.

1 Like
8

This topic was automatically closed after 2 days. New replies are no longer allowed.