Thanks for reporting this; I can replicate this bug and see the following in the browser console:

<br/><b>Fatal error</b>:  Uncaught Error: Call to undefined function normalizer_normalize() in /var/www/html/quickstatements/public_html/quickstatements.php: 603 Stack trace: #0/var/www/html/quickstatements/public_html/quickstatements.php(593): QuickStatements-&gt;compareDatavalue(Object(stdClass),
Object(stdClass))#1/var/www/html/quickstatements/public_html/quickstatements.php(1176): QuickStatements-&gt;getStatementID(Object(stdClass))#2/var/www/html/quickstatements/public_html/api.php(254): QuickStatements-&gt;runSingleCommand(Object(stdClass))#3{
    main
}thrown in<b>/var/www/html/quickstatements/public_html/quickstatements.php</b> on line <b>603</b><br/>

Pull Request: https://github.com/wbstack/quickstatements/pull/136

A fix for this has just been shipped to production.

It seems that unfortunately the fix didn't solve the issue, although I notice a change: once the batch encounters one of the 3 cases described above, before today it remained stuck in "run" status, whilst now it gives an "error" with no motivation and goes to the next edit. But effectively it is not yet able to save correctly the edits in cases 2 and 3 (for case 1 no edit should be saved, so, although seeing an unnamed error is not ideal and it would be better do see instead "done!" with the message "the value already exists", the present situation is fine because the main issue was the batch being stuck).

the present situation is fine because the main issue was the batch being stuck

This behavior is indeed not ideal, but if this is to be improved, we should do it upstream instead of at wikibase.cloud level. In any case improving the error handling further would be out of scope for this ticket.

Not exactly. Above I wrote:

In case 1, the second command line should be skipped (as the statement already exists) and the next command line should be executed; in cases 2 and 3, all the command lines should be executed normally

Now case 1 is solved, as I said in the parenthesis, but cases 2 and 3 are not solved; so solving cases 2 and 3 is in the original scope of the ticket.

In T365916#9860166, @Epidosis wrote:

Not exactly. Above I wrote:

Now case 1 is solved, as I said in the parenthesis, but cases 2 and 3 are not solved; so solving cases 2 and 3 is in the original scope of the ticket.

Hello,
Could you please clarify how cases 2 and 3 behave now for you and what is the expected behavior?
Thanks!

As of now, in cases 2 and 3 the command is skipped by QuickStatements giving "Error!"; so the edit which should be saved by these commands are not saved; this is highly problematic. Hovering on the errors I get no further information. To be clear, in cases 2 and 3 _edits need to be saved_ (in case 2 the edit should add a further value of a property already having one or more values; in case 3 the edit should add a qualifier to an existing value)

Also in case 1 the command is skipped by QuickStatements giving "Error!" but in that case no edit should be saved (because the value I'm trying to add exists already), so - as I said - case 1 can be considered somehow find as of now.

Could you maybe provide a full "as-is" input that you are trying to process? I just tried reproducing case 2 again and it worked as expected (adding both statements) for me using

Q15	P3	"1"
Q15	P3	"2"

which gave me https://mw138test.wikibase.dev/wiki/Item:Q15 without errors

Case 3 also passes for me using

Q2	P3	"case3"
Q2	P3	"1"	P4	Q1

I tried again today and all the three cases work perfectly as in Wikidata; probably when I tried yesterday afternoon the fix had not been deployed yet on the Wikibase Cloud instance I was using (i.e. https://datalib.wikibase.cloud/).
Thanks very much for the fix!