Hey PlayCanvas team! We’re having issues with playcanvas-sync where it’s getting weird results from the List Assets REST API (Assets - List assets | Learn PlayCanvas).
We have 4504 assets and the playcanvas sync lists assets in 1000 item pages. However, when I run the script it’s missing some assets. When I increased the limit to 5000, it seems all assets are sent correctly. The limit is defined in the load-assets.js file using the constant ASSET_QRY_LIMIT. playcanvas-sync calls the rest with query parameters limit and skip to get all the assets.
This seems to be an issue in the REST API, because we have an asset that is included in the response when the limit is set to 5000 and is on the index 909. When running with limit 2000 it’s still there on index 909. However when running with limit 1000, it’s no longer present.
Yes, but also it might not be. Running playcanvas-sync’s pcsync diffAll results in “Local Files Missing on Remote” even though these files are on remote. And when I changed the limit, it no longer has those missing files.
I just double-checked, this has to be an issue with the REST API. I ran the list assets using cURL with query parameters: limit=1000 and skip=0, all the way to skip=4000 (even tried skip=5000) and combined the responses into a single file in terminal. Then I searched through the file to find an asset and it wasn’t there.
I then did limit=5000&skip=0 and it contained the asset.
Hi TadeasKriz!
I’ve just verified our backend code and tested some different use-cases and came to these conclusions:
The code is taking limit and skip parameters correctly, with the same logic as other APIs we expose;
I’ve tested locally with CURL many different setups and it seems to be working correctly;
The code does differentiate between calls from the Editor and calls from API Tokens (created from your https://playcanvas.com/account), in that it ignores limit and skip for Editor calls - which is suspiciously similar to the behaviour you’re facing.
Can you verify that the API Token you’re using (i.e. the one used in the header "Authorization: Bearer <TOKEN>") is valid token created from your account page? Additionally, you can check the following fields in the JSON response from the API call:
thanks for looking into it. I’m no longer able to reproduce it. Is it possible there was a bug in the API? Because before I could reproduce it each time I’ve tried. So it seems like a bug that got fixed in the meantime.
Yea, it is possible that we had a bug. We’ve been improving our backend reliability lately, so there could have been an issue that is now solved. Thanks for checking!