For Combu Client/Server 3.2.4
We're having an issue posting to Leaderboards which seems to be most easily reproducible on our WebGL deployment. Combü calls to register, login, auto login, save custom data, load custom data, read leaderboard data, etc. all seem to work just fine. Posting scores to leaderboards however is inconsistent.
In the WebGL build, if a user logs in (or auto logs in) and posts to our leaderboards right away (there are 4 boards we report to), the scores get posted without issue. Afterwards, when completing a game session (with cheats enabled, takes about 20 seconds), we save the user's custom data and post to leaderboards. This posting and all subsequent posting attempts fail, yet saving succeeds. This is not the case within the Unity editor as both saving and posting to leaderboards seem to work consistently.
We set the server config to stop encrypting its responses and discovered the following in the browser console after it attempts to post to a leaderboard:
success false message "User is not authenticated" errors []
Even stranger, if we check just prior to posting whether the user is authenticated with "CombuManager.localUser.authenticated", it always returns "true".
We are totally stumped at this point. Any help you could provide here would be really appreciated. Thanks!
This is a pretty strange behaviour, I'll try to reproduce it locally in an WebGL build. Does it happen every time or does it randomly work?
By the way, could you eventually create an empty WebGL project where this scenario is reproduced (included the changing of the active scene, if your app also changes scene after the login screen; and just use a WaitForSeconds(20f) to emulate the ending of the game session) and sharing the code by PM/email with me (of course I don't need the full game code, just the sequence of calls to Combu server)? Just to be sure that there's nothing interferring with the requests to the web services.
FRANCESCO CROCETTI @ SKARED CREATIONS
Thanks as usual for your quick response!
The issue is indeed inconsistent which has made it very difficult to track down but I believe we've found the issue. I'll know more after more testing but I believe it's related to how we are re-establishing communication with the server after a failed ping. I'll post a follow up when I know more.
