The scenario: One user has 2 browser windows pointing to the same channel with the extension open.
They useBits on one window -> onTransactionComplete is called on both.
I use onTransactionComplete to know when a user has actually spent bits and I can safely trigger the action they paid for. In my case, I call my EBS. In a scenario like this though, I end up calling it twice and thus triggering the same action twice.
Both actions are triggered pretty much at the same time, so there is no time for me to write the timestamp to my DB and try to read that on the second call in an attempt to invalidate it.
Do you have any similar scenarios? How do you deal with them? Is there another way to know for sure that a user has now spent their bits?
Just for clarity, regardless of the broadcast setting Twitch will ALWAYS send a receipt to onTransactionComplete for ALL connections by a user on the channel where they have used bits.
Personally I just use a basket flow, sort of, and have had no issue with it. If the user has something selected and has clicked useBits (regardless of if they actually use confirm that within that tab) they’ll send any transaction they get back to my EBS, first one there is considered the definitive source of data for me. If a tab got a receipt but a nothing selected, or they never attempted to call useBits then the frontend for that tab just assumes it wasn’t a transaction for their tab.
Another alternative is to use ‘tokens’. For example if a sku is to get ‘gold tokens’, then the EBS can credit those ‘tokens’ to the users account and this can completely ignore any duplicate transactions as no meta-data or state needs to be sent from the user to your EBS. Then the user can use those ‘tokens’ in your extension to do whatever it is they need to do, and there’s no issue with duplication there as it’s directly between a client and your EBS.
Each useBits transaction has a single id, regardless of how many tabs that receipt is sent to. I could be sent a thousand to my EBS, 1 id = 1 transaction = 1 increase in ‘tokens’ by the SKU used. Once the ID is in the database, all future messages sent to the EBS with that ID can be dropped.
The problem being EBS gets two Transactions at the same time and is processing transaction B whilst Transaction A is being written to the database. (Where transaction B is a duplicate of Transaction A)