Unrecoverable SQLExceptions like "ORA-00942: table or view does not exist" doesn't make the task state to change from RUNNING to FAILED. The same happens with other Oracle errors like (usable to extend tablespace).
[2020-07-24 13:52:17,937] ERROR Failed to run query for table TimestampIncrementingTableQuerier{table=null, query='SELECT * FROM MY_TABLE', topicPrefix='my-topic', incrementingColumn='EVENT_ID', timestampColumns=[EVENT_TIMESTAMP]}: {} (io.confluent.connect.jdbc.source.JdbcSourceTask)
java.sql.SQLSyntaxErrorException: ORA-00942: table or view does not exist
Should
not throw an exception?
Running Confluent open source distribution 5.5.1.
hi @fabiodellanna ,
try to add schema.table_name to you FROM.
I also see this as a big problem - even a query successful at the beginning can transition into broken state when e.g. a column is removed from the table and one can only find it by looking in the logs.
All alerting systems based on connector status won't capture this...
I also see this as a big problem - even a query successful at the beginning can transition into broken state when e.g. a column is removed from the table and one can only find it by looking in the logs.
All alerting systems based on connector status won't capture this...
I'm just experiencing this issue right now. Something unadivertasely changed in one of the database object my source connector was depending on, making the It to fail to poll records from there. On this case, my telemetry system was saying it was everything all right, for days...
We're also seeing issues similar to this where the connector and tasks all report as running, and yet for some reason messages stop being produced. No errors as far as I can see in logs.
Only way to capture this is to monitor messages being produced to the topic and alert when it unexpectedly drops to zero.
Most helpful comment
I also see this as a big problem - even a query successful at the beginning can transition into broken state when e.g. a column is removed from the table and one can only find it by looking in the logs.
All alerting systems based on connector status won't capture this...