In the Oracle connector, there is a concept of in-flight schema change events that happen under a particular configuration:

• store.only.captured.tables.ddl must be set to true
• the table must exist prior to being added to the table.include.list

When a DML event is observed for a table in the table.include.list but that does not yet have a matching Table in the relational model, the Oracle connector emits an in-flight schema change event.

On the surface, this is not a problem and works well; however, if the transaction that contains the DML event that triggers the in-flight schema event later fails before it commits or rolls back, the next reprocessing of that transaction, a new in-flight schema change event is emitted, leading to duplicates in the history topic.

Duplicates in the main schema history topic are not a problem for recovery; however, if the user has configured the include.schema.changes option also creates duplicates in the user-facing schema change topic. Since Debezium is marketed as an at least once delivery solution, this isn't a problem, but does require a solution for consuming applications to handle this.

As a solution:

The obvious is to implement Exactly Once Delivery, but we need a mechanism to associate the in-flight schema change with a reasonable scope.

The idea is then to modify the relational model immediately so that we can support the lookup and processing of future DML events that are buffered for the table in question; however, we would not immediately dispatch the in-flight schema change event to the topic but instead would buffer the schema change event in a unique buffer. On the subsequent transaction commit/rollback, which signifies a checkpoint, we can safely drain the in-flight schema change buffer just before the transaction dispatch.

However, there is still the possibility that if the connector observes some failure during the transaction commit consumer loop, the event could be still be re-emitted, but this should be a significantly smaller risk. Moreso, this prepares for when EOD (Exactly Once Delivery) is implemented as the EOD boundary will solve this remaining corner case by packaging both the transaction and the schema change emission in the same transaction boundary, causing it all to be written or all to be rolled back in the topics.

Questions / Concerns:

We need to test the impact on Oracle RAC. For example, can we flush the schema change if Node A triggers the in-flight schema change event but then Node B performs a commit? The offsets associated with the in-flight schema change event will refer to Node A and not Node B details, so i would likely suspect we cannot. In this case, this introduces a complexity where we may need to also manage what happens when both Node A and Node B trigger in-flight schema changes for the same table; how do we coordinate this, or can we?