Transaction retry in Ballerina 2201.x: work that falls outside the transaction manager

Ballerina's transaction statement in Swan Lake 2201.x wraps a block of work in a local or distributed transaction and supports optional retry, rollback and commit clauses. Connectors such as mysql:Client and postgresql:Client participate through the transaction manager, and transactional named workers extend that participation across workers.

The unresolved part is the boundary. Operations issued through clients that do not participate in the transaction — an HTTP call, a file write, a message publish — are not enrolled, so a rollback does not undo them and a retry can execute them again. The language does not prescribe how such effects should be reconciled with the transactional work.

Verification is a design decision as well. Confirming that a rolled-back transaction left no rows behind requires a read performed outside the transaction, and the isolation level or snapshot appropriate for that read is not fixed by the language.

Open questions

• Which operations should be assumed to sit outside the transaction manager in a given 2201.x distribution?
• When retry re-executes a block, what guarantees apply to side effects from non-participating clients?
• What read strategy verifies post-rollback state without re-entering the same transaction?