What is the design reason behind Spring not executing nested @TransactionalEventListener listeners?

Hello, Spring Team.

I initially posted this question on Stack Overflow, but a reviewer determined that it's a question only the Spring maintainers could answer, which has prompted me to open this issue.

I'm working with Spring's transactional events and have come across a situation where chaining BEFORE_COMMIT event listeners does not work as one might initially expect.

Here is an example scenario:

// (1)
@Transactional
public void saveFoo(Foo foo) {
    applicationEventPublisher.publishEvent(new FooEvent(foo));
}

// (2)
@TransactionalEventListener(phase = TransactionPhase.BEFORE_COMMIT)
public void handle(FooEvent event) {
    barService.saveBar(new Bar(event));
}

// (3)
@Transactional
public void saveBar(Bar bar) {
    applicationEventPublisher.publishEvent(new BarEvent(bar));
}

// (4) but not working (not listening)
@TransactionalEventListener(phase = TransactionPhase.BEFORE_COMMIT)
public void handle(BarEvent event) {
    quxService.saveQux(new Qux(event));
}

My Investigation

After debugging, I believe I've found the technical reason for this in TransactionSynchronizationUtils.triggerBeforeCommit.

public static void triggerBeforeCommit(boolean readOnly) {
    for (TransactionSynchronization synchronization : TransactionSynchronizationManager.getSynchronizations()) {
        synchronization.beforeCommit(readOnly);
    }
}

It appears that when the commit process begins, the list of currently registered TransactionSynchronization objects is captured. The triggerBeforeCommit method then iterates over this captured list.

Even if a new TransactionSynchronization is registered from within this loop, the list being iterated over has already been fixed. As a result, the newly registered TransactionSynchronization is not called during the current phase.

My Question

I understand what is happening, but I would like to understand the design rationale behind this behavior.

Why was this intentionally designed this way?

Is it to prevent potential infinite loops of events? Or is it to ensure that the set of operations within the commit phase remains deterministic and cannot be modified during its own execution?

I would appreciate it if anyone could share insights into the intended design or point to any relevant documentation or discussions on this topic.

Thank you!

Start with TransactionSynchronizationUtils.triggerBeforeCommit and the nested @TransactionalEventListener example described in the issue. Review how transaction synchronizations are captured and invoked, then check the surrounding transaction-event documentation for relevant guarantees. Done means providing a documented design rationale or maintainer explanation for the observed behavior.