plaid: Handle DEFAULT_UPDATE
and TRANSACTIONS_REMOVED
webhooks.
#144
Labels
api
Related to or caused by the backend Go REST API.
enhancement
New feature or request
plaid
Anything to do with the Plaid integration.
production
Something needed for initial production release.
transactions
Milestone
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 thelimit
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.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 theDEFAULT_UPDATE
webhook handling we check for thepending_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.
ORIGINAL: monetr/rest-api#169
The text was updated successfully, but these errors were encountered: