Hi brainCloud team,

Thank you for the detailed explanation.

Based on your answer, I understand that Redemption Code should not be treated as the source of truth for production reward fulfillment / recovery state, especially for shared or multi-use codes.

For our current implementation, we are handling it like this:

Redemption Code is used for campaign validity, shared-code redemption, and reward metadata. The Redemption Code custom metadata contains only a rewardDataId / rewardId. The actual reward content is resolved on our server from our RewardData. Reward fulfillment is executed by our server reward pipeline. Separately, we store a per-user claim state in a BrainCloud User Entity / Custom Entity. That claim state records statuses such as Redeeming, Redeemed, Granting, Granted, RedeemFailed, and GrantFailed. If redemption succeeds but reward fulfillment fails, we keep the claim state as Redeemed or GrantFailed and allow our server to retry the fulfillment step without requiring the user to redeem the shared code again. If the claim state is Granted, we block duplicate reward grants.

So in our design:

Redemption Code owns code validity and whether the user has consumed the shared code. Our separate claim entity owns fulfillment state, retry state, and audit/recovery information. Redemption Code redeemed records are not used as the production recovery source of truth.

Does this align with the pattern you recommended?

Also, as a follow-up, we are currently calling BrainCloud from our server for multiple steps: claim state update, redemption, reward grant, and final claim update. We may consolidate the BrainCloud-side claim/redemption operations into a CloudCode script to reduce API round trips, while still keeping reward fulfillment in our server pipeline.

Would that be a reasonable approach?

Thanks again.

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.