Davin Chia (Airbyte)
AirbyteConnectionStatus
will get us most of the way there in terms of user errors (don’t expect authentication/networking information to change often, is that a wrong assumption?) The alternative is amending the other protocol methods to allow them to also pass more detailed errors; obviously a bigger change.CheckConnection
):
• We actually do not report operation failures if the CheckConnection
operation fails. This is because we report failures based on the job outcome. So even though the `StandardCheckConnectionOutput`’s status field is set to FAILED
here, we still report this as a success here. This is a bug that should be fixed.
• We don’t actually track jobs the first time a source/destination is set up (e.g. the onboarding flow) as scope is null. We are potentially missing data here. I see this was implemented explicitly in this PR. Should we change this?
• I’m not sure if the way we have it set up propagates temporal exceptions to the client. Something like this doesn’t propagate and temporal keeps on trying. I’m still looking into this (@Jared Rhizor (Airbyte) do you know?)