Hi all, I’m currently testing Airbyte in my team. ...
# ask-community-for-troubleshooting
m
Hi all, I’m currently testing Airbyte in my team. What is the recommended way to “test” a connector? I do a full sync of all tables (by default) from a connector and get some errors (datatype mismatch between data and destination) for a few tables resulting in a failed sync. I remove the troublesome tables from the sync list and re-run the sync. The unmarked tables enables to go further in the sync and then I encounter new errors. I’m loosing a lot time because of the sync duration in-between sync failure. Should I instead test table one by one? More generally, how Airbyte deals with these kind of errors, eg. when only a single table sync fails? Do we have to re-run the sync for all the tables? Or am I missing something? Thanks in advance 🙏
1
👀 1
h
Hey Michel it would be more helpful if you can share those logs. We are always here to help you in making this happen.
m
Hello Harshith, thanks for your reply, I have shared 3 log files for each source we are testing. • Stripe: it seems there’re a 400 HTTP error when getting
subscriptions
information. • Mailchimp: the worker seems to stop itself, I’m not sure what is the cause of this. • Pipedrive: Same as Mailchimp?
More generally, what is Airbyte retry strategy in case of a sync error? My current understanding is: • Run sync • Get an error for a table • Keep going on the other tables • Finishes the sync, detects the initial error • Do a new attempt (again full sync)
h
• Run sync • Get an error for a table • We don't do for other tables • Finishes the sync, detects the initial error • Finish normalization if any • Do a new attempt (again full sync)
👍 1
m
Thanks !
u
@Michel Yeung what instance size are you using? The error 143 shows the container was killed, possible by Memory/GC issues.
m
Hello @[DEPRECATED] Marcos Marx, i’m using t3.large right now