rahul_anand
08/20/2020, 5:31 PMdouwe_maan
08/20/2020, 5:32 PMrahul_anand
08/20/2020, 6:25 PMtap is created for generic use case so it may be ok for tap to flag as error and stop, but the orchestrator has a bigger responsibility to implement different workflow requirements of various use cases.
Can Meltano have some intelligence with its state data to understand re-try configuration and try few times before giving up? And also continue downloading other objects excluding the failed object.douwe_maan
08/20/2020, 8:11 PMretry: 3 setting to have meltano elt retry itself (or just the tap) just in case a failure was recoverable, but that wouldn’t help if one object was fundamentally broken and in downloadable.
I’m not sure how Meltano could detect a broken object and then specifically decide to skip it (or its entire stream), though, since it wouldn’t know what caused the tap to fail, not even the specific kind of object (stream) it was trying to download...
How about we explore either or both some more in an issue? :)
Would you mind creating those, with a description of your use case and specific problem, and any thoughts you have on how we might implement these or any other potential retry strategies?rahul_anand
11/09/2020, 3:24 AM--select to pass failed object and remove --full-refresh flag, on retry of the elt pipeline. A retry feature will be really helpful.douwe_maan
11/09/2020, 4:33 PM