You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using Stitch and replicating Stripe every 30 minutes. As you can see in the screenshot below, for the last 12 hours, the payout_transactions table has replicated 8,701 rows every 30 minutes.
My guess is that it's selecting the latest payout (because it's >= the created) of the latest replicated one), and then querying Stripe for all balance_transactions related to that payout. In my opinion, it should either (a) use > for payouts, instead of >= or (b) keep the latest payout.id in addition to the created date, and if we've already replicated that id, don't bother fetching the balance_transactions to fill in the payout_transactions sub-stream.
The impact of the current behavior is (1) waste of requests to Stripe and (2) a lot of unnecessary additional cost on Stitch.
The text was updated successfully, but these errors were encountered:
I am using Stitch and replicating Stripe every 30 minutes. As you can see in the screenshot below, for the last 12 hours, the
payout_transactions
table has replicated 8,701 rows every 30 minutes.My guess is that it's selecting the latest
payout
(because it's>=
thecreated
) of the latest replicated one), and then querying Stripe for allbalance_transactions
related to thatpayout
. In my opinion, it should either (a) use>
forpayouts
, instead of>=
or (b) keep the latestpayout.id
in addition to thecreated
date, and if we've already replicated thatid
, don't bother fetching thebalance_transactions
to fill in thepayout_transactions
sub-stream.The impact of the current behavior is (1) waste of requests to Stripe and (2) a lot of unnecessary additional cost on Stitch.
The text was updated successfully, but these errors were encountered: