Thanks Paul, that makes sense.

For now, we’ll keep using a dedicated internal/service profile with getSessionForProfile() + callAPIForSession() as a temporary workaround for our monthly transaction reporting job.

Could you please confirm whether this workaround is safe to use temporarily in production, as long as we do not include a profileId in the search criteria and only use the session to authorize the request?

Also, we’d appreciate it if you could let us know once the S2S proxy hookup for SYS_GET_TRANSACTIONS_PAGE has been reviewed or fixed.

Thanks again for checking into this.

Added the additional details to 13660

Q1: The removed player is completely excluded from reward calculation, so if the deletion happens before the job runs, that player is never iterated over and receives no rank or rewards.
Q2: Yes, the modified score will be used. The job always reads live state. Note that whether the score actually gets modified depends on the leaderboard type (e.g., for the LOW_VALUE type, only updates if the new score is less than the existing)
Q3: No backfilling, the next joiner goes to the latest instance, not the freed spot in ^2. No loop over earlier instances (^1, ^2) ever happens. The next joiner goes to ^3 (or ^4 if ^3 is full). The freed spot in ^2 stays empty permanently.

brainCloud developers have just release several playable builds of our famous examples! See our cool features in action. Find them at https://getbraincloud.com/demos for Windows, Mac, online and mobile.