How to queue up failed cloudscript executions triggered from PlayStream events?
I trigger a CloudScript from user_vc_item_purchased that calls a Webhook to my external server for purposes that aren't relevant here.
Naturally, the webhook provided may go offline (for a few minutes or longer). It's very important that this event is relayed to my server sooner or later.
What would be the suggested method to queue up such failed "event side-effects"?
One solution in my mind was to have a scheduled task that checks a queue every 5-10 minutes. If it finds any entries made by an exiting triggered CloudScript, it can take relevant action. In this case, however, I'm stumped as to what I could use as storage for the queue.
Additional note: I am not referring to the Webhook menu in Game Manager, but api POSTs in cloud script.
Currently, it seems my only avenue is to waste some of the entity data.
Failed webhook call -> Registered in relevant Player -> Next time server submits same request -> First checks entity data if that request has been applied already -> If yes, resends the failed webhook call
I believe this workaround should be feasible. If configured properly, there should be very few failed Cloud Script executions, and creating Scheduled Tasks for it is not cost-effective. The main idea is to aimed at those players who have failed calls, instead of iteratively checking all players.
In a perfect solution, I wouldn't have iterated over all players. If I had some persistent storage where I could keep a queue of failed calls, the scheduled task could've used it. Depending on the usage pattern, the cost could be fairly low.
Please take a look at this:
https://community.playfab.com/idea/44070/creating-non-player-entities.html
If the scenario is multiple writes at a short time, PlayFab will hardly support it because there is no queued resources supported. Entity Objects support data version and every entity (title, group, players) should be able to use objects via SetObjects/GetObejcts, but it cannot guarantee to meet your requirement. An external Database might be a better workaround solution.
