I can't reproduce it on the latest 3.16.0 version, it works as expected.
Here is a sample of my script:
$myJSONRPCClient->delete_participants($sessionKey, $survey_id, [4, 5]);

delete_participants functions was last changed 15 months ago, so it should work fine.
Check your script, maybe you have mismatch for aTokenIDs variable or some strange characters.

Ok, i did some more investigating.

• Calling delete_participants with an array of tokenIDs results in the SQL error. This is true for 1-element arrays but also for arrays with multiple elements
• Replacing the 1-element-array of tokenIDs for a single value without array notation prevents the error, but doesn't actually delete anything
• Calling a delete_participants with a tokenID that doesn't exist, correctly returns "Invalid token ID" without any errors
• Adding tokenIDs to the array as a String or an int both return the same result

Updating from 3.15.9 to 3.16.0 (with comfortUpdate) doesn't make a difference. I still have an old instance with version 3.5.4 running that also still works (just like the 3.14.9 that i updated this limesurvey instance from originally)

By the way, i tried deleting a participant form a newly created survey instance (created after the update) and from an existing survey definition (created in 3.14.9). Both give the same results

I tested it right now again, using postgresql database, but it still deletes records without any errors ( using 1 or more elements in an array).
Problem is probably related to JSON-RPC client you are using.
I'm using weberhofer/jsonrpcphp package.
Can you try using this package?
Or any other JSON-RPC client?

Ok, here's the result with Postman as my JSON-RPC client. (see attached files). These are the same actions as i described above.

result_postman_existing_id.png (86,866 bytes)   

result_postman_existing_id.png (86,866 bytes)   

result_postman_non-existing_id.png (88,226 bytes)   

result_postman_non-existing_id.png (88,226 bytes)   

sql_exception_postman_existing_id.png (60,708 bytes)   

sql_exception_postman_existing_id.png (60,708 bytes)   

I switched to Rested extension for firefox and tried again.
When I used your syntax it failed, but it works when I provide parameters in key: value format.
See attached screenshot.
Try it like that.

Screenshot_2019-03-20_13-57-14.png (51,353 bytes)   

Screenshot_2019-03-20_13-57-14.png (51,353 bytes)   

Unfortunately, that didn't change anything. It seems like it does in fact do some resolving of the ID, because it can correctly identify when i'm trying to remove a single non-existing ID, but other cases just fail

other-syntax.png (68,179 bytes)   

other-syntax.png (68,179 bytes)   

other-syntax-no-array.png (79,947 bytes)   

other-syntax-no-array.png (79,947 bytes)   

other-syntax-non-existing-id-in-array.png (81,266 bytes)   

other-syntax-non-existing-id-in-array.png (81,266 bytes)   

Something that just came to mind. I'm doing this with an API user that only has the attached permissions.

Now that i think about it i think my initial description may have been too limited. This is what happens in more detail:

• User 1 (with permissions described in permissions-creator.png) creates the survey in the limesurvey admin page
• User 1 adds user 2 (different account, permissions described in permissions-api-user.png) to the survey in survey-permissions.
• User 1 gives user 2 has all available permissions, see survey-permissions.png (user 1 is CJGR admin, user 2 is CJGR API user)
• External application logs in through remotecontrol API, using credentials from user 2
• User 2 activates the survey
• User 2 adds participants
• At some point user 2 can delete participants if needed. This is the step that fails.

For completeness: both users are in the same usergroup.

Note that i did not change the setup or the permissions recently. In 3.14.9 these steps worked fine with these permissions.

Additional note: The API user (user 2) should not be able to touch any surveys it has not explicitly been added to. I have experienced that the only way to achieve that is by only giving it create survey permissions (which i thought was weird, but it does work).

permissions-api-user.png (60,985 bytes)   

permissions-api-user.png (60,985 bytes)   

permissions-creator.png (61,695 bytes)   

permissions-creator.png (61,695 bytes)   

survey-permissions.png (20,468 bytes)   

survey-permissions.png (20,468 bytes)   

Yes, giving user2 right to create surveys is only possible solution right now, because there isn't global permissions for tokens.

So, aside from the hint about the survey permissions (thanks for that), anything else i can try to prevent this SQL error or help you debug it? I have a feeling it's not so much related to the REST-interface, because if i provide an id that doesn't exist it returns exactly what i expect it to return. That to me means the interface itself is working just fine.

Yes, you are correct, REST-interface works as expected when parameters are provided.
SQL error is shown only when aTokenIds parameter isn't accepted by REST-interface.
Correct parameter format is very important to be able to prevent this issue from happening.

SQL error is shown only when aTokenIds parameter isn't accepted by REST-interface.

Then we must prevent this in API : if an invalid aTokenIds is set return error with status=>'Invalid aTokenIds in request'

But it is accepted. I did the exact same call twice, i only changed the value of the tokenid. Once with id 1 (SQL error), once with id 123 (correctly handled with a readable status-message). I don't see how that change would result in the REST-interface not accepting the parameter, because the difference in results depends on the actual database content. I feel like we're focussing on the wrong part of the application here. Like you stated, the REST-interface works as expected.

See https://bugs.limesurvey.org/file_download.php?file_id=11346&type=bug
vs
https://bugs.limesurvey.org/file_download.php?file_id=11347&type=bug

Some JSON-RPC clients use parameters definition like this : $myJSONRPCClient->delete_participants($sessionKey, $survey_id, [3, 4, 6]);
But it is not a case for your client.

Can you try again using exactly the same structure as I used here: https://bugs.limesurvey.org/view.php?id=14601#c51064?
It looks that if browser REST extension is used for sending requests, you have to provide parameters in key: value format.

I test with PostgreSQL 9.1.24lts2 to have a PG test : really can‘t reproduce Tested:

• 1 : return empty string : OK
• [1] : existing : OK deleted
• [1] : exiting with response : OK deleted
• [1] : not exist : OK return invalid
• [1,2,3,4,5] some existing , some not exist : OK for all

Set to Unable to reproduce on 3.16.1 : please update

@DenisChenu: see my last note.
It looks like Postman use different parameter definition.
Can you try to reproduce using Postman?
https://bugs.limesurvey.org/view.php?id=14601#c51064

OK : the fix is here : https://github.com/LimeSurvey/LimeSurvey/commit/3579c93e529792463e8b3fe44671830fe78d06f3

@dominikvitt the SQL error is duie to old code
$dlquery = 'DELETE FROM '.TokenDynamic::tableName().' WHERE tid=:tokenid';
, moved to clean code.

We must remove all this direct SQL instruction ;)

Even after updating to 3.17.3 this was still an issue. I've finally figured out what the problem is!

The issue is in the auditlog plugin. If i enable the auditlog plugin i get the SQL syntax error when deleting the survey. Disabling the auditlog plugin also fixes the error.

@ginosupport:
I'll try to fix it this week.

Any progress on this (maybe on the 4.0.0 branch?)? We've been missing the auditlogging for a while now and would like to re-enable it.

I have the same problem in version 3.19.3+191023

Does https://bugs.limesurvey.org/view.php?id=15651 fix this too?

It does for me - but can you please confirm it for you?

Waiting for confirmation that it has beens solved.

I've just checked on 3.22.7 and the problem is fixed now. Thanks!