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
{{ message }}
This repository has been archived by the owner on Jun 19, 2023. It is now read-only.
We've noticed an issue for syncs that complete quickly after being started by the FivetranOperator. The FivetranSensor starts and begins polling after the sync has completed, so it continuously receives a scheduled state until another sync is triggered or it's marked as SUCCESS externally. This leads to long-running sensors (daily syncs for e.g.).
You should be able to reproduce this with a connector that syncs quickly and a sleep operator between the fivetran_sync_start and the fivetran_sync_wait.
We've solved this by (1) removing the fivetran_sync_start >> fivetran_sync_wait dependency between the operator and the sensor so the sensor task doesn't block the operator task (2) setting sensor priority > operator priority so the sensor starts shortly before the operator.
(Seems like something like #49 may solve this. Perhaps identifying syncs could as well?)
The text was updated successfully, but these errors were encountered:
Thanks Alexander, we are solving this in the next release of the provider with XCOMs. I should have this release out and instructions on how to use the provider w/ XCOMs this week, I'll then post the instructions here and close this issue
Hi, thanks for the work on this provider.
We've noticed an issue for syncs that complete quickly after being started by the
FivetranOperator
. TheFivetranSensor
starts and begins polling after the sync has completed, so it continuously receives ascheduled
state until another sync is triggered or it's marked as SUCCESS externally. This leads to long-running sensors (daily syncs for e.g.).You should be able to reproduce this with a connector that syncs quickly and a sleep operator between the
fivetran_sync_start
and thefivetran_sync_wait
.We've solved this by (1) removing the
fivetran_sync_start >> fivetran_sync_wait
dependency between the operator and the sensor so the sensor task doesn't block the operator task (2) setting sensor priority > operator priority so the sensor starts shortly before the operator.(Seems like something like #49 may solve this. Perhaps identifying syncs could as well?)
The text was updated successfully, but these errors were encountered: