Posting a copy of the AWS service health page for posterity.

It mostly refers to the outage impacting DynamoDB - but a lot more services than that were impacted. We expect that just means that a lot of AWS services use DynamoDB under-the-covers to operate.

2025-10-20_05-58-47.png

Hi,

Actually - voting leaderboards are implemented via the PostScoreToLeaderboardOnBehalfOf() call - where you can basically vote for someone else's score. [i.e. voting for that person].

Create the leaderboard as a "Cumulative" leaderboard - and basically the player votes for the score of another player - incrementing it by +1.

I suppose we should add those details to the roadmap item!

I hope that helps to clarify things!

Paul.

As I mentioned in the support chat - the issue is that midnightPSTinUTC isn't dynamically calculated for midnight today -- it's midnight PST on Oct 4th. [i.e. over a week ago].

What's happening is the call is accepting that past date - which puts the script in the front of our queue to be run ('cause we think we're late!) - and it gets run in the next 60 second job interval. And then reschedules itself in the past again.

So basically this script is running roughly 60*24 = 1440 times a day.

Anyway - I'll have the devs look into it - we should return an error if you are scheduling the script too far into the past... [i.e. a second or two in the past is probably fine - and best to do in case the scheduling script has delays of some sort... but clearly 10 days in the past is too far! Probably 60 mins in the past is too far! 🙂 ]

Thanks for reporting this. I’ll forward it to our team and get it fixed.

HI @richard - we're currently working on a feature that will handle this directly for brainCloud 5.9.

In the meantime, an interim approach would be to:

Manage the Lives in a virtual currency. In the item catalog - you can indicate the currencies to award from the offer via the extra data JSON. And create a post-hook on PurchaseUserItem - calling a script to award the appropriate currencies - and immediately consume the new "item" that was purchased...

Just a thought...

[But yeah - we're going to have a more direct solution in 5.9 - which is currently targeted for November release.]

Paul.

@devsleeper - we hope you like it! 🙂

Just a heads-up, our team is working on this bulk userItem feature.

@JasonL
Yes we can do that too, I was just wondering how granular our control over the segment is, as one of the requirements for our testing was to have a precise number of users for each group.

Thank you so much for the info, I'll write again if I have more questions.

Hi @Paul-Winterhalder

I wanted to follow up regarding StoreKit 2 JWS receipt support.
At the moment, Unity IAP v5 relies on StoreKit 2 by default, but there are two major issues we’re facing in production:

VerifyPurchase currently only supports StoreKit 1’s PKCS#7 receipt format.
When StoreKit 2 is used (as in Unity IAP v5), the App Store often returns empty receipts in certain environments — especially on Apple Silicon (M-series) Macs running iPadOS compatibility mode — causing verification to fail and users to lose their purchases.

In addition, Unity IAP v5 has a known issue where after the first successful purchase, all subsequent purchases return the same receipt as the first transaction.
This makes it impossible for the server to distinguish or validate new purchases, since every transaction reuses the initial receipt data.

Both of these problems make proper validation impossible under StoreKit 2, and they directly affect live monetization and user trust.

If StoreKit 2 JWS receipt support could be prioritized or exposed as a secondary endpoint (for example, itunes2), it would help developers transition more safely.
Given the impact, we would really appreciate if this work could be accelerated.

Hi @richard,

Hmm - yeah - I don't think that JSON is currently editable in the portal.

Paul.

@JasonL @Paul-Winterhalder Thanks for your help, the error no longer appears after the Google Android platform was enabled.

My view is that there should be a "guaranteed service availability" at the time of purchase not unlike buying an appliance with a year warranty..

Pull the game from stores and let the remaining players enjoy the sunset.
Of course it's not always as simple as "just keep the lights on longer" but a guaranteed period of availability which is tied to new purchases should be in your plans before your service ever reaches the public, rather than hoping to grab as much money as possible before dumping it and throwing the consumer under the bus.

And... the upgrade is complete.

Hopefully a non-event for everyone!

Reach out to support if you see any weirdness!

Cheers,

Paul.

Oh - and one thing that wasn't in the release notes... we bumped up the Design Portal session timeout -- so if you go away from the portal and come back to it later -- there's a better chance that you can pick up from where you left off (instead of being booted and having to re-login).

Ah! Thanks for letting us know!

@JasonL
Thank you for the info, much appreciated!

Okay - cool!

สวัสดี ต้องขออภัย แต่เราให้บริการช่วยเหลือเป็นภาษาอังกฤษเท่านั้น

[Hi. Apologies - but we only provide support in English.]

You can schedule a recurring daily cloud code script to run after the completion of your daily tournament. This script will use the GetGlobalLeaderboardPage method to retrieve the daily tournament winner's information and score, then post it to the monthly tournament using the PostTournamentScoreOnBehalfOf method.