A @Transaction annotation can close the connection prematurely.

[sdedic]

Expected Behavior

A call to a method annotated with @Transaction completes without error (provided there are not DB-related errors etc).

Actual Behaviour

The application throws

io.micronaut.data.connection.exceptions.NoConnectionException: No current connection present. Consider declaring @Connectable or @Transactional on the surrounding method
	at io.micronaut.data.connection.exceptions.NoConnectionException.notFoundInAdvice(NoConnectionException.java:49)
	at io.micronaut.data.connection.jdbc.advice.ContextualConnectionInterceptor.intercept(ContextualConnectionInterceptor.java:58)
	at io.micronaut.aop.chain.MethodInterceptorChain.proceed(MethodInterceptorChain.java:143)
	at io.micronaut.data.connection.jdbc.advice.ContextualConnection$Intercepted.getTransactionIsolation(Unknown Source)
[...]
	Suppressed: io.micronaut.data.connection.exceptions.NoConnectionException: No current connection present. Consider declaring @Connectable or @Transactional on the surrounding method
		at io.micronaut.data.connection.exceptions.NoConnectionException.notFoundInAdvice(NoConnectionException.java:49)
		at io.micronaut.data.connection.jdbc.advice.ContextualConnectionInterceptor.intercept(ContextualConnectionInterceptor.java:58)
		at io.micronaut.aop.chain.MethodInterceptorChain.proceed(MethodInterceptorChain.java:143)
		at io.micronaut.data.connection.jdbc.advice.ContextualConnection$Intercepted.getTransactionIsolation(Unknown Source)
		at org.jdbi.v3.core.Handle.setTransactionIsolationLevel(Handle.java:836)

Steps To Reproduce

1. Checkout the app from https://github.com/sdedic/micronaut-dbbugs1
2. The state is marked as report1
3. Run the application with parameter -1 , i.e. mvn exec:java -Dexec.arguments="-1"
4. observe the stacktraces

Environment Information

• Ubuntu Linux 22.04
• Oracle JDK 21
• Micronaut version 4.6.2, 4.7.6

Example Application

https://github.com/sdedic/micronaut-dbbugs1

Version

4.7.6

[sdedic]

According to my debugging, the bug is caused by misordering PropagatedContext.Scope registrations in suspendOpenConnection.

The method first establishes a new current PropagatedContext with the current (being suspended) Connection removed; then it calls a connection-creating callback, in my case openNewConnectionInternal that makes another PropagatedContext.Scope and registers it for cleanup. only after that the PropagatedContext.Scope from suspendOpenConnection is registered (last), which means that during cleanup, the PropagatedContexts are restored in wrong order, effectively clearing Connection information from the PropagatedContext.