@Paul-Winterhalder Thank you for your reply.

To give you more context, we operate three separate app environments: Dev, Staging, and Production.

We frequently execute deployments to the Production environment during live operations, but only after safely completing all tests in Staging. However, every time we do this, the "App is disabled" error occurs temporarily, which in turn causes our custom user scripts to fail.

Experiencing this issue periodically during live operations is negatively impacting our service quality.

Is there any way to prevent this situation? At the very least, is there a specific scope or option within the Deploy API that allows us to push updates without triggering the "App is disabled" state?

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.