Hi, I have the "so famous" java.sql.SQLException: YEAR error (using MySQL connector). I know you wont or cant fix it, but I'm wondering how I can reproduce with more information : I want to know which line(s) and which column(s) are responsible for this error : any idea ? (My skills in Java are ... close to none)

Hi, @Mickaël Andrieu, as a general note - we are a small team and do our best to prioritize and fix issues to make Airbyte better. Java knowledge is not required for tracking down issues, please make sure to use the search feature in GitHub as well as the labels specific to all the connectors in our catalog. Here is the line: https://github.com/airbytehq/airbyte/blob/c596e6ed09bc6331a5ec586c20423a1ff7783de6[…]io/airbyte/integrations/source/mysql/MySqlSourceOperations.java There is an issue open regarding this: https://github.com/airbytehq/airbyte/issues/8722 As well as a discussion as to why this issue has not been fixed: https://github.com/airbytehq/airbyte/issues/8722 Hope this helps!

Hi @Nataly Merezhuk (Airbyte), this doesn't help me 😕 Again, I don't ask for a fix but help to reproduce and better figure out which lines or columns or tables are involved on the exception which is triggered with no extra information. Airbyte job is not to deal with errors in databases, but as I'm able to access the database with a SQL client and DataGrip with no warnings or errors, I don't know WHY my sync task is not working anymore. This is not about improving the behavior of the connector (you can't), but document how we can learn more from a failed task. What could be perfect when an exception is thrown would be to add in logs the SQL query involved 🙂

The best way to understand why a sync isn't working is to look through the complete logs, look at the exceptions and errors there. Could you provide the full logs?

There is no information in logs about the core issue (this was because on a old MySQL Database the developers have setup the defaut value for dates to 0000-01-01), what could be nice is when there is an issue to be able to see which SQL query was involved. In my case, instead of spending an entire day to figure out why and one more 1/2 day to convince the dev team (because I had no explicit error about it in my logs), this could be solved in 1/4h (UPDATE on base + UPDATE on Table structure to change the default value to 0000-00-00)

@Mickaël Andrieu, if you don't think debugging would be helpful and have an idea for the solution, please create a feature request on GitHub. Sorry to hear this is causing frustration for you.