Skip to content

Conversation

@astitcher
Copy link
Member

This is the work in #437 just about ready to be merged.

@astitcher
Copy link
Member Author

I've spent today carefully considering the behaviour of the code and API design with respect to message settlement and disposition under various conditions and I've concluded that the API and implentation currently does not offer the required support for a transactioned API.

Specifically:
Most importantly: In the case that the broker fails a commit the C++ code has no way to know for sure which messages are concerned - either because they are now released back to the client in the case of a sent message or because the disposition update sent for them by the client is now undone. In either case the client has to do work unrolling or redoing work.

  • I think to make this easier we need a separate commit failed callback whilst still keeping the existing transaction failed callback

Settlements aren't handled correctly - the basic reason you'd want transactions in the first place implies that you need to delay settlement until after transaction commit, but our code does not do this - it doesn't even acknowledge you'd want to do this.

  • The practical way to achieve this would be to only allow a transactioned session to contain transactioned messages and then to settle every message in the session after a successful commit. The simplest way to do this in this API is to fail to transition to a transacted session if there are any unsettled messages on the session -- I think we need to implement this.
  • This also means that for transaction controlled messages/disposition updates we should not support immediate settlement but always defer until transaction discharge, but then in the happy path the API needs to handle the settlements itself.

@astitcher
Copy link
Member Author

We also need some way of testing the error/unhappy cases - so the transaction tester needs to simulate a broker failing commit and also doing some things that are illegal in the AMQP transaction protocol.

@gemmellr gemmellr marked this pull request as draft December 9, 2025 15:36
@astitcher astitcher force-pushed the cpp/local-txn/precommit branch from c276b7b to 184806f Compare December 9, 2025 22:39
@astitcher astitcher force-pushed the cpp/local-txn/precommit branch from 184806f to a3e4fd4 Compare December 11, 2025 01:11
@astitcher
Copy link
Member Author

I've done a lot more work on this now, and I'm getting a lot happier about the correctness of its behaviour for outgoing messsages. I think the settlement behaviour for these is now correct under successful commit and also rollback.

I've enhanced the python broker some more and I think it now actually represents most of the transactional behaviour of a spec correct broker. It would be good to add a way to make it fail to commit - perhaps adding a transaction timeout timer would be a realistic way to do this.

Rollbacks shouldn't settle incoming deliveries.
We added new callbacks for transactioned delivery updates. These have a
different meaning from the regular delivery updates as they are
provisional on the transaction successfully committing, so should be
separate callbacks.
Also fleshed out the behaviour of the callbacks and tightened the
settlement behaviour for outgoing messages on transaction aborts.
Add option to send a bad message (with no 'to' address) which should
force the broker to reject it.

Add an option to rollback a transaction after a certain number of
messages.
@astitcher astitcher force-pushed the cpp/local-txn/precommit branch from f8e9918 to 9db81aa Compare December 12, 2025 05:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants