Can you give us more detail on what was the original API call?

Looking at the history, I think I know what's going on here. Frontend and API usually send baserevid and that determines what's going to change on the item, if it thinks that it's going to change the label, it's going to try to make sure it doesn't violate the uniqueness constraint, I suggested back then to make sure you remove self-conflict errors for this exact reason, we never know if it would make its way to conflict check or not. First, let me reproduce it and then apply a fix.

I'm using the Addwiki library to save a new revision. The data that is sent to the API can be found in P10226 (was a lot of information, so a paste would be better than dumping it in here. (As serialized by the Addwiki library)

Okay I found out what's wrong, it's the "clear" option. It messes with perception of ChangeOpResult, because it think it added everything again. This is causing all sorts of problem like edit summaries like this: https://www.wikidata.org/w/index.php?title=Q81715970&diff=prev&oldid=1096133130 The API request with "clear" true errors out but works just fine if you remove the clear option.

In T243158#5819801, @Ladsgroup wrote:

Okay I found out what's wrong, it's the "clear" option. It messes with perception of ChangeOpResult, because it think it added everything again. This is causing all sorts of problem like edit summaries like this: https://www.wikidata.org/w/index.php?title=Q81715970&diff=prev&oldid=1096133130 The API request with "clear" true errors out but works just fine if you remove the clear option.

Then I need to dig in the Addwiki package to find out how to disable the clear. Because it gets added there.

Found the culprit in vendor/addwiki/wikibase-api/src/Api/Service/RevisionSaver.php :

// Always clear so that removing elements is possible
                        $params['clear'] = 'true';

And I can't override it in my code, so the solution has to come from the addwiki/wikibase-api package.

I think it needs slightly more work than that. The current problem can be solved in several layers, we should fix it on our side as well but I really appreciate if addWiki don't send the whole entity, just diffs what's added and removed.

For the addwiki part talk to @Addshore he's the maintainer of the addwiki code

I submitted https://github.com/addwiki/wikibase-api/pull/57 to remove the clear parameter from addwiki/wikibase-api/src/Api/Service/RevisionSaver.php as it isn't needed to remove a statement.

Sending diffs is better, but requires more work in the code, which I'll leave to others.

Actually I have an idea that might not be too complicated to write, it's basically diffing and patching. Are you working on it already @Addshore ?

Change 568066 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/Wikibase@master] Validate ChangeOp against the current entity instead of an empty one

https://gerrit.wikimedia.org/r/568066

Change 568490 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/WikibaseLexeme@master] Throw right exception when trying to apply change on non-existent subentity

https://gerrit.wikimedia.org/r/568490

Change 568490 merged by jenkins-bot:
[mediawiki/extensions/WikibaseLexeme@master] Throw right exception when trying to apply change on non-existent subentity

https://gerrit.wikimedia.org/r/568490

Change 568066 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Validate ChangeOp against the current entity instead of an empty one

https://gerrit.wikimedia.org/r/568066