MSQL Source SQL Exception Month/Year

  • Is this your first time deploying Airbyte?: Yes
  • Memory / Disk / CPU: 16Gb ram, 50gb, 8core / 16 logical processor
  • Deployment: Docker Desktop
  • Airbyte Version: 0.39.37-alpha
  • Source name/version: MySQL 0.5.6
  • Destination name/version: Postgres 14
  • Step: Issue is happening on sync
  • Description: I have two connectors with mysql and both keep failing either with sql exception of MONTH or YEAR for the either.

logs-13.txt (1.0 MB)

I did additional tests by creating a view from the original table without date related fields (strings) and sync was successful, there seems to be an issue with one of the date columns regarding to the data maybe.

Not sure how and what to find.

Hello and welcome to the Airbyte community, @antonapua! It looks like you may be passing the wrong format in date related fields. Could you try using an instance of LocalDate instead of a string?

Hi @natalyjazzviolin,

I am not sure what LocalDate you’re referring to, is that Java? I don’t have access to change the existing mysql table not control over what data goes into it.

I did create a mysql view table and tried to apply CAST as DATETIME() however, I still encountered the same issue.

Issue seems to be related to Source MySQL: Connector fails if source contains "tricky" date values · Issue #3931 · airbytehq/airbyte · GitHub however I thought it’s fixed already.

applied zerodatetimebehavior=Converttonull still having the same issue
logs-99.txt (2.6 MB)

From the latest logs it looks like the problem is now in DAY_OF_MONTH. I found another related issue that’s been resolved:
https://github.com/airbytehq/airbyte/issues/5070

I think the best course of action is to escalate this to GitHub, so I’lll do that next!

Please feel free to add any details here:
https://github.com/airbytehq/airbyte/issues/15161

1 Like

Hello again, @antonapua. Could you retry - looks like the issue might have been fixed!

Hi @natalyjazzviolin,

We’ve managed to solve the issues, we just had some really old rows that weren’t conforming to a date pattern. We had to manually fix those by a combination of by updating records and creating a view table to aribyte to use rather than the actual table.