brainCloudAdmin group

Paul Winterhalder

Hmm - we'll look into it. Definitely looks like it isn't hooked up to the S2S proxy properly.

Thanks for reporting this.

johnh

@Ali-Raza could you let me know your Team ID and the AppIDs you would like this increase for? thanks

johnh

Added case 14121

johnh

Hi @Omar-Alzayed When apps have millions of users, browsing all users can have poor performance.
If you have a smaller number of users, it can be useful.
There is a way to create a segment so you can browse all your users.

Go to App > Design > Segmentation > Segments
Create NEW SEGMENT

There's a couple different ways you can return ALL users. The one I like is to use the criteria A/B Testing ID 0-99 which will return all your users.

Looks something like this:

Segments are automatically run nightly at around 3am but you can press REFRESH SEGMENTS to run it immediately.

Note that the refresh will take time to complete according to your user count, you may wish to do this during low player traffic.

In the case of this particular segment, I believe the Refresh will need to run TWICE to capture all your users. (I think the AB code needs to be initialized in the first pass, and then it can be read in the second pass, capturing all of your users.)

Please take care not to launch the second Refresh before the first one completes. (If you have 10,000+ players then wait about 30 minutes or so)

Once you have players in the Segment, you can browse by Segments. Go to
User > User Browser

Choose BROWSE, then check the box to browse within a segment. Choose the segment.

Reminder, once you have millions of users, this can be very slow. But you can create more refined Segments to filter to just the interesting users, such as Has Bought Something, Is at Least Level 10, and so on.

Segments allow compound conditions so you can really filter to exactly who you want.

Segments can also be used to target Sales and Promotions to specific player groups. For example you could create a $0.99 one-time, loss leader promo that is available to only those players who have not bought anything in your game yet. It's a very powerful system.

Could you let me know if this helped you?
Thanks
John

JasonL

Yes, your current design matches the recommended pattern: Redemption Code is a one-way gate for “has this user consumed this shared code?”, while your claim entity is the authoritative state machine for fulfillment, retries, and audit (Redeeming → Redeemed → Granting → Granted / GrantFailed), with Granted as the idempotency guard for duplicate grants. The main thing to watch is call ordering: it’s preferable to write the claim to Redeeming first as an intent record, then call redeemCode(), so any Redeeming with no further progress is detectable and recoverable by your server without depending on the Redemption Code record.

Consolidating the brainCloud-side claim init + redemption into a single CloudCode script is a good fit, provided the script is strictly idempotent and fulfillment stays in your server pipeline. The script should read the claim state, upsert to Redeeming if needed, call redeemCode() (skipping if already Redeemed or beyond), update the claim to Redeemed, and return rich state (claimState, claimId, rewardDataId) so your server can then perform fulfillment and issue a final Granted / GrantFailed update. This gives you a clean two-call pattern from the server to brainCloud on the happy path, while the script’s state checks make retries safe even though CloudCode itself is not transactional.

JasonL

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.

Paul Winterhalder

Hi @moondory77 ,

Yes, you observed correctly.

During the data migration portion of the deployment (which occurs after the system has done a bunch of validation and consistency checks), the system temporarily disables your app to do the actual data migration.

This is to protect the data integrity of your app - as your app's metadata, reference data and cloud code scripts are all changing underneath it. So we disable the app, make the changes, and re-enable the app.

All of this normally takes just a few seconds - though it does depend upon the number of changes being made.

I hope that helps to clarify things!

Paul.

johnh

Submitted case 14062, case 13344

Thanks @noah I will keep you updated

johnh

Hi @noah thank you for your help explaining your needs.
I think I have a better understanding of your request.

I have redone the mockups so it is clearer the materials will be consumed. I think these new mockups are closest to the feature set you are requesting. Could you let me know?

ITEMS
In this mockup, the player would need to pay 10 coal, plus the required components to get the Trusty_Steel_Sword.

The operator can specify a mix of Virtual Currencies, and a count for each component.

CASH PRODUCTS
In this mockup the player can make a cash purchase provided they have the required materials, which will be consumed to issue a Premium Steel Sword.

Upon choosing to edit the Required Materials, the operator would be presented with edit panels that follow the existing Cash product functionality.

Pressing the edit pen would look like this

Once I have your confirmation, I will present your request to the team at the next Product Design meeting.

Let me know,
Thanks
John

Paul Winterhalder

Hi @noah,

I agree that this would be a good feature.

I've been doing some thinking on it...

What if we could restrict an S2S server to only being able to call a specific set of scripts? That way you would be in full control as to the scope of the API that you are making available.

Would that work for your use case?

Paul.

brainCloudAdmin

Posts

Member List