Bug report

[Originally posted to https://github.com/quarkusio/quarkus/issues/39848]

I'm trying to apply the transactional outbox pattern for inter-microservice communication. In order to ease that, I tried out the Debezium Quarkus Outbox Reactive extension, since I'm using the reactive programming approach (this includes hibernate-reactive with panache, pg-reactive client, etc.).

As consistency is really important in my project, after having written the necessary code, I first checked to see if the entity's database is modified in the same database transaction as the outbox table's insert (AFAIK this is an essential part of the transactional outbox pattern).

To my surprise, the outbox extension starts a new, separate transaction for this insert, no matter how I tried to control the transaction boundaries (I followed the respective guides on quarkus.io, tried wrapping the whole code with Panache.withTransaction() or annotating the method with @WithTransaction, without luck).

Am I missing something here, or could it be that the "same transaction" aspect of the outbox pattern was forgotten in the reactive debezium outbox extension?

Thank you for your help in advance!

P.S.: I found these lines that I think are related to this issue. For me it does not seem like the extension tries to make sure that it reuses an already existing transaction, but I can easily be wrong here.

What Debezium connector do you use and what version?

Not relevant as the issue is related to the quarkus debezium outbox (reactive) extension and it happens before reaching the debezium connector.

What is the connector configuration?

Not relevant, see above.

What is the captured database version and mode of depoyment?

Postgresql 10.23 running on on-prem OpenShift.

What behaviour do you expect?

When using the Debezium Quarkus Outbox Reactive extension, the modification in the entity table of the database should happen in the same database transaction as the insert to the outbox table caused by the outbox extension, as per the transactional outbox pattern.
This transactionality is essential to guarantee consistence between the service's inner state and the services observing its outbox table for communication.

What behaviour do you see?

I checked the transactions with Postgres using the virtual transaction IDs and also by defining constraints to make the entity update fail, but the outbox insert did not fail with it, so it couldn't have been in the same transaction as the update (it should have also been rolled back).
Examining the virtual tx ids resulted in the same finding, the two are unfortunately separate transactions.

Do you see the same behaviour using the latest relesead Debezium version?

(Ideally, also verify with latest Alpha/Beta/CR version)

The extension's currently installed version is 2.2.0.Final, I haven't tested it with 2.5.2.Final yet (which I see as the latest version on the quarkus extension page).

Do you have the connector logs, ideally from start till finish?

Not relevant, see above.

How to reproduce the issue using our tutorial deployment?

Use the reactive debezium quarkus outbox extension to use utilize the transactional outbox pattern in a quarkus application, and check the (virtual) transaction IDs of the entity modification and the respective outbox insert database operations.

In my case they are different, meaning that they are executed in separate transactions, which undermines the main goal of the transactional outbox pattern.