- Ya
- 27 Agosti 2026, 09:19 UTC
- Mwandishi
- Kamo
- Ahadi ya
- ae984f7
Prompted by a peer session finding a @Transactional(REQUIRES_NEW) Spring never advised — protected, and self-invoked, so the record of a failed query rolled back with the query it was recording. Scanning this service's own annotations for both shapes turns up one self-invocation, and it is worth a note rather than a change. setupForSubOrgCreation(Long, …) is REQUIRES_NEW and reached across a bean boundary, so it is advised. The overload it then calls is @Transactional and is NOT: a call that never leaves the object never passes through the proxy. That is harmless here, and only here, because REQUIRES_NEW has already opened a transaction and REQUIRED means "join the current one" — which is what happens regardless. What it is not is a safety net, and this file has already paid for that confusion once. Removing REQUIRES_NEW above does not fall back to the overload's annotation; it falls back to none, and every write is silently discarded on the afterCommit path — every organization created between 3903267 and the propagation fix got no subscription row at all for exactly that reason. Moving the entry point without moving the annotation does the same thing. **************** pins the outer annotation; nothing can pin a reader's assumption about the inner one, so it is written down. Comment only. No behaviour change.