In this instance I think the situation is much simpler. It looks like a save button (with a custom microflow behind it) is executed for a second time before the first execution is finished. This simply means the 2nd execution tries to create the same object (with the same id) a little bit later than the 1st execution. Causing this error to be thrown. A simple way to resolve this would be to use the "disable during action" option (see https://docs.mendix.com/refguide/action-button#disable-during-action-only-for-microflow-actions)

It seems this error is happening a lot lately :)

We now had this issue also. In my opinion this is a combination of a modeler error and a Menidx bug. We had this issue  in a microflow when we had a new parent object where a couple of new child objects where created. While committing the child objects list this error would pop up because the parent object needs to be autocommitted and there the Mendix bug pops up. Mendix should not throw an error in this situation in my opinion. Sollution is to do the commit of the parent object first.

Regards,

Ronald

Hi Fabian,

I ran into this once when I added an extra association between to entities. The first association was many to one. The second was many to many with the owner set to default (i.g. the same object as the previous association). This resulted in the same reference Id being stored in the object twice (or more). Is this maybe the case in your project? 

Best regards,

Serge

I always noticed this in a Client where the environment is with 2 mendix servers hosting same app and a load balancer in front. Apparently in those hurried clicking attempts the calls are being split and 1 server takes too long time to server while the other finishes. And yes, Disabled During Action never solved this case.

Is there an update on this?

Disabled during action never solved it for us either.

Mendix points to network issues and TCP resets, but I question it. We suddenly started getting these errors a lot after upgrading from MX6 to MX8.

I suspect there are problems with their load balancer. How can a request which creates a new object take a while and then be executed twice by the client after not receiving an answer, or, a different request creating an object with the same ID as the other request which takes a while?

Hi Fabian,

I have run into this issue when restoring a database and not restarting the application with an on-prem application. From what I have learned this should technically never happen as Mendix is handling the creation of the ids. That being said, are you using any SQL to insert data into your application?

Often you can fix the issue using the Uniqueness Constraint Migration toolkit. Ask Mendix support for it and they can send the MPK file to you, which helps you detecting and solving the uniqueness violation. https://docs.mendix.com/refguide/uniqueness-constraint-migration

We encountered similar issues a high concurrency application. Probably Mendix could not process the concurrent events correctly. 

Did you recently switch from uniqueness violation check by runtime to database?

Hi Fabian,

Did you ever land on what was causing this issue for you? We are currently seeing experiencing this behavior intermittently as well. 

Thanks,