Posts

---

Question about using unique indexes for Custom Entities
• P Paul Winterhalder

  Hi @gyutaelee,

  The unique option has been added to the existing followerId_followingId index of the FOLLOW custom entity.

  I also added it to the staging and production apps in the same team.

  Have a good week!

  Paul.
  [PS - we have plans to allow the creation of unique indexes via our portal soon...]

---

Question about using unique indexes for Custom Entities
• J JasonL

  Hi @gyutaelee, thanks for the detailed request. We will add a unique compound index for your FOLLOW Custom Entity.

  About Your Questions:

  1. Will this unique index auto-deploy to Staging/Production?
     No. Because brainCloud's API blocks unique indexes at the code level (to prevent sharding issues), the deployer does not know about manually added indexes.

  2. Does this need to be applied per app/environment manually?
     Yes. Each brainCloud app (Dev/Staging/Prod) is a separate appId with its own physical MongoDB collection.

  3. Can we provide appIds for Dev/Staging/Prod so you can add the index to each?
     Yes, absolutely. Please reply with the App IDs for your Staging and Production environments. Once we have them, we'll apply the same unique index to all three environments.

  4. Are manually added Custom Entity indexes included in deploy/migrate/export-import workflows?
     No. The deploy pipeline is config-driven. Any index added directly via MongoDB (outside the Portal/API) is invisible to ImportExportService.

  5. If there are existing duplicate rows, will unique index creation fail?
     Yes. MongoDB returns duplicate key error and aborts the entire index build. Since you mentioned the feature isn't in production yet, you can safely reset/clean up FOLLOW data before we apply the index to avoid this. We may need to check for duplicates first.

  6. Is there expected downtime, lock, write failure, or performance impact?
     No hard downtime Index builds are non-blocking: reads and writes continue during the build.

  7. How to verify the unique index exists after application?
     You can verify it from the Indexes tab of app/design/cloud-data/custom-entities/FOLLOW from portal, or call the method sysListIndexes() via API Explorer.

---

Questions about brainCloud Friends and Social Leaderboard behavior
• J JasonL

  Hi @gyutaelee ,

  Thanks for the detailed questions.

  1. Friend Relationship Direction - Yes, bidirectional

  • AddFriends: When user A calls AddFriends([B]), both A and B see each other in ListFriends("brainCloud")
  • Both A and B will appear in each other's GetSocialLeaderboard results (if they have scores)
  • RemoveFriends: Removes the relationship from both users atomically

  2. Idempotency - Yes, both are idempotent

  • Calling AddFriends([B]) when already friends: No-op, no error thrown (skips DB write)
  • Calling RemoveFriends([B]) when not friends: No-op, no error thrown

  3. Consistency and Caching - Immediate

  • Friend changes are persisted immediately to the database (no write-behind caching)
  • ListFriends("brainCloud") and GetSocialLeaderboard reflect changes immediately after AddFriends/RemoveFriends
  • No eventual consistency or caching delay

  4. Friend Count Limits - No hard cap

  • No code-enforced limit on brainCloud friends per user
  • Practical consideration: Friend IDs stored as array on UserProfile; very large arrays (>10K) may impact read/write performance

  5. GetSocialLeaderboard Behavior - Returns all friends + self + pacers, no limit

  • Returns all recognized friends + self + pacers
  • No hidden maximum result count
  • Pacers are included (if leaderboard has pacers configured)
  • Warning: Response payload grows linearly with friend count

  6. Recommended API for Top-N - Yes, use GetMultiSocialLeaderboard

  • GetMultiSocialLeaderboard with a single leaderboard ID is a correct approach for top-N results
  • leaderboardResultCount is applied after social filtering and score sorting
  • leaderboardResultCount is capped by maxMultipleLeaderboardScoreLimit app property (default 10, can be raised in app-basis)
  • Preferred over GetSocialLeaderboard for top-N because it has built-in truncation

  7. Social Leaderboard Pagination - Not supported

  • No GetSocialLeaderboardPage API exists (only GetGlobalLeaderboardPage for global leaderboards)
  • Social leaderboards always return the full friend set (potentially truncated by leaderboardResultCount only in the multi variant)
  • I will forward your pagination request for team review

  8. Billing and API Counts - 1 API call per request

  • GetSocialLeaderboard = 1 API call regardless of friends/entries returned
  • GetMultiSocialLeaderboard = 1 API call even with multiple leaderboards
  • AddFriends/RemoveFriends = 1 API call even though they modify both users' profiles

  9. Recommended Usage - Yes, your design aligns perfectly

---

Question about using unique indexes for Custom Entities
• J JasonL

  Hi @gyutaelee,
  Currently, brainCloud blocks unique indexes on all custom collections as a blanket safeguard. The check happens unconditionally before the system even evaluates whether your collection is owned or sharded, so it rejects the unique option with that error.

  We can manually add the unique index for your FOLLOW collection on our end. Please send us a request with:

  1. Your appId
  2. The entityType (is it FOLLOW only?)
  3. The field name(s) that need uniqueness
  4. The desired index name (e.g., test_index)

  Once we receive your request, we'll add the uniqueness constraint for you directly.

---

Automated Promotion not associated for users already in target segment
• P Paul Winterhalder

  Ah - great to hear @jongdae-won . Thanks for the update!

---

Automated Promotion not associated for users already in target segment
• P Paul Winterhalder

  That patch has been deployed @jongdae-won - give it a try!

---

Automated Promotion not associated for users already in target segment
• P Paul Winterhalder

  Hi @jongdae-won,

  We have a patch being deployed today that will allow you to create promotions that will allow you to target both existing and new members of a segment. We plan to have that deployed by the end of the day.

  

  We hope that this will address the primary issue.

  Your latest message seems to indicate that even new users to a segment are not getting the promotion offer... that does seem odd. I will point out that segments only get refreshed nightly and upon login - so if a new stat meant that they should be added to a new segment - the new segment and/or promotion wouldn't be refreshed until they logged back in again...

  Unless... your app is making this call before it brings up the store:
  https://docs.braincloudservers.com/api/capi/appstore/refreshpromotions

  Could that be [that specific] issue?

  In any event - we are hopeful that the patch should address your primary concern. We'll post here once it has been deployed.

  Paul.

---

Admin Billing API request
• P Paul Winterhalder

  Hi @dbgtdbz2 - we certainly don't have an api for that sort of thing right now.

  Can you send a private chat in via the support system - addressing me - and give me a heads up of what you're up to?

  Thanks!

  Paul.

---

Admin Billing API request
• J JasonL

  I’ll forward your request to the team for review...

---

Automated Promotion not associated for users already in target segment
• J JasonL

  Yes, the behavior you’re describing is expected with the current implementation. RefreshMySegments, RefreshPromotions, and login will not attach the promotion to users who are already in the segment, because the system is designed to only grant automated promotions when the user enters the segment (i.e., when it shows up in enteredIds). The fact that Reset Segments or Re‑evaluate All Segments fixes it is also expected, because those actions force the user back through the segment‑entry logic.

  We’re working on a fix to make this smoother. The practical effect going forward will be that, when a new automated promotion is created or attached to an existing segment, the next segment refresh will automatically apply it to all currently‑eligible users in the background, without you needing to reset or re‑evaluate segments manually. This should make the behavior more predictable, especially when you have a large number of existing users already in that segment.