Handle DEFAULT_UPDATE and TRANSACTIONS_REMOVED webhooks.

[elliotcourant]

Handle Transactions webhooks DEFAULT_UPDATE and TRANSACTIONS_REMOVED if your app needs to keep Transactions data up-to-date. For more details, see Handling Transaction webhooks.

• DEFAULT_UPDATE is currently handled by retrieving the last 7 days worth of transactions for the specified item ID. If it is guaranteed that the new transactions are always the first ones to be returned, then we could set the limit of our request to the number of new transactions to improve efficiency.
• TRANSACTIONS_REMOVED is completely implemented however need to be checked for correctness, at the time of writing this it had a bug that prevented it from working. Update as needed.

[elliotcourant]

There is a small issue here with the implementation.

We often receive the TRANSACTIONS_REMOVED webhook before the default update. This means that if a pending transaction has a "spent from" then it is lost when the non-pending transaction is created.

With how closely these webhooks can be dispatched I'm concerned that it might be hard to mitigate this behavior.

My thought is that when the TRANSACTIONS_REMOVED webhook is received we cache the spent from for the removed transaction in redis with a short TTL. Then in the DEFAULT_UPDATE webhook handling we check for the pending_transaction_id in redis and see if it has a spent from. If it does then we allocate that spending automatically.

My worry is that if these webhooks are not handled one after another, or if they are handling in the wrong order or at the same time then this behavior will be inconsistent at best.