Hello BrainCloud Team. @Paul-Winterhalder

I am submitting this inquiry again as it seems some context might have been missed when I left it as a comment in another question thread.

This is an extension of the following inquiry:
https://forums.getbraincloud.com/topic/369/inquiry-regarding-temporary-app-is-disabled-error-during-builder-api-deployment

As a quick reminder, our service operates across dev, staging, and production environments using three separate BrainCloud apps. We maintain a zero-downtime deployment scenario by deploying the contents tested in dev/staging to production via the builder deploy API.

However, as mentioned in our previous inquiry, the "App is disabled" state occurs temporarily during this process, causing all BrainCloud APIs to fail. Since our service relies heavily on BrainCloud for much of our backend infrastructure, this causes a significant degradation in our user experience.

The issue is that while we understand this state might occur during heavy updates like cloudcode deployments, it also happens when we only migrate specific specs like customEntity. This creates a problem even when we are just trying to apply minor specs to the production app space.
(Since you mentioned in the following inquiry that there are no plans to provide a bulk update API for customEntity, we currently have no alternative: https://forums.getbraincloud.com/topic/372/subject-inquiry-regarding-selective-customentity-migration-via-builder-api/2)

Therefore, we would like to request the following:

Please provide a minimum-unit migration option that does not trigger the "App is disabled" state. (We strongly hope customEntity can be included in this option, and it would be even better if productPricing and itemCatalog could also be included.)

If (1) is not possible, please provide a means to bulk update/migrate customEntity at the very least, without triggering the "App is disabled" state.

We have been able to provide a truly excellent service to our users thanks to the BrainCloud infrastructure. We sincerely hope you can support us in this matter so that we can continue to deliver a seamless and positive experience to our users.

Hi,

API calls triggered by the backend DO count towards API usage -- so using the API Explorer to make calls do get counted as API calls. So - if you use API explorer to trigger a user batch job that then runs scripts on all of your users - yes, yes that does get counted as API calls. 🙂

Also - uploads of files to and from the portal do get counted in the file transfer costs.

Other normal portal operations - like viewing users, viewing logs, editing scripts, etc - do NOT get charged in API counts. So to clarify - using the API explorer to view a leaderboard is going to add an API count - but using the leaderboard viewer at App > Global > Leaderboards > Leaderboards does not!

To be honest - in general - usaging of the portal is negligible. You won't really notice the usage added by what you're doing in the API explorer or working through the portal. It's only if you use the API Explorer to kick off a large job that API counts would be noticable <-- as you'd expect!

I hope that helps!

Paul.

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.