Thank you! it was great help

Hi @noah , brainCloud 6.0.1, which will be released next week, adds new data stream events for virtual item purchases. We'll keep #2 and #3 in mind as we continue to evolve things going forward. Thanks for pointing out MongoDB CDC - I wasn't familiar with that capability before. We'll take a harder look at it. Cheers! Paul.

Hi BrainCloud Team, Following up on our earlier Campaign discussion — we tested the new S2S operations introduced in 6.0.1 (SysUpdateCampaignJson / SysUpdateScenarioJson) against our dev app, and SysUpdateCampaignJson consistently fails with "Unrecognized request." Test campaign: CMP_TEST_01 (status: In Progress, no end date — never expires) Confirmed server version (via client GetServerVersion, authenticationV2/GET_SERVER_VERSION): "serverVersion": "R6.0.1-194" So the app is already running 6.0.1, not an older build. Request (via S2S Explorer, flat single-operation format): { "appId": "{Our_AppID}", "serverName": "{Our_ServerName}", "serverSecret": "***", "service": "campaign", "operation": "SYS_UPDATE_CAMPAIGN_JSON", "data": { "ccCall": false, "campaignCode": "CMP_TEST_01", "version": -1, "campaignJson": { "theme": "winter", "bannerId": 7 } } } Response: { "reason_code": 40001, "status_message": "Processing exception: Unrecognized request: service=campaign, operation=SYS_UPDATE_CAMPAIGN_JSON.", "status": 400 } What we've already ruled out on our side: Campaign state/schedule — campaign is active and never expires. Plan/tier gating — LiveOps Campaigns menu is visible and campaign creation works in our portal, so this isn't an Enterprise-tier access issue. serverName — retried with the correct registered credential name ("{Our_ServerName}" instead of a placeholder "CloudCode"); identical error. Request format/casing — matches the same convention as other SYS_ operations we already call successfully (e.g. SYS_UPDATE_ENTITY, SYS_GET_SEGMENT_LIST). reason_code 40001 semantics — confirmed via the C# client SDK's ReasonCodes.cs that 40001 (INVALID_REQUEST) is a generic shared bucket code, not specific to "campaign ended" (that would need a distinct message string, which we did not receive — ours literally says "Unrecognized request"). Version rollout timing — directly disproven; GetServerVersion confirms 6.0.1 is already live on this app. We also tried a session-based (client-authenticated) call to the same operation, which returned 403 Forbidden instead of 400 — a different error, but we don't think it's a clean comparison since Sys* operations are S2S-only by design. Given the operation is documented, listed in the 6.0.1 release notes as live, and selectable in the portal's own S2S Explorer, but still fails with "Unrecognized request" on a fully up-to-date app with valid credentials, we suspect either the operation isn't fully wired into the S2S dispatcher yet, or there's some app-level/credential-level permission gate we're not seeing. Could you confirm whether SYS_UPDATE_CAMPAIGN_JSON should be callable for our app as-is, or if there's an additional enablement step on your end? Happy to provide additional repro details (packet IDs, timestamps, etc.) if useful. Thanks.

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.