• Discuss all the things!

    172 Topics
    645 Posts

    For a shared/multi-use Redemption Code, a specific user’s redeemed record can only be reset or deleted through the tester-only deleteRedemptionForTester() flow, so there is no supported production operator/API path for non-tester accounts, and the tester reset should be treated as a QA/dev tool rather than a live recovery mechanism.

    If reward fulfillment fails after redemption, it does not provide an automatic recovery or re-execution path that restores the same user’s redemption state in production; synchronous failures record a failed attempt, async flows can end in Failed on timeout, and any retry is only possible if the code type’s maxRetries still allows another user-initiated redeemCode() attempt.

    customRedemptionInfo can be used as a persistent per-user audit field if your fulfillment script writes it back, since it stores the script response on the user’s code record. However, it is not designed to be updated later through a direct external API after the fact.

    The tester reset is explicitly intended for testing/cleanup only, not as a production recovery operation.

    For production operational rewards, the safest pattern is a shared Redemption Code for claim detection, plus a separate Custom Entity for the fulfillment state, which provides auditable handling of pending/fulfilled/failed/retrying without relying on the Redemption Code record as the source of truth.

  • Suggestions for improvements, new features, etc.

    44 Topics
    151 Posts

    Submitted case 14062, case 13344

    Thanks @noah I will keep you updated

  • Questions specific to particular APIs, libraries, etc.

    64 Topics
    267 Posts

    Added the additional details to 13660

  • General cloud code discussions...

    35 Topics
    149 Posts

    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's online learning tutorials and examples.

    3 Topics
    3 Posts

    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.

brainCloud 5 is alive!

brainCloud 5 features Portal-X (our next-gen portal), Integrated Forums (you found them), our new Bootcamp training videos, and more!

Join the discussion here!

brainCloud Bootcamp!
brainCloud's new video learning portal is now online! Go check out brainCloud BootCamp!

Need to report a defect?
Use the chat widget from the Design Portal - or send an email to support at getbraincloud.com. Thanks!