Request for Lazy Transaction Initialization in BeginCommitRollback Middleware

[mscno]

Hi, I'm using your BeginCommitRollback middleware in an app with conditional transaction needs.
First off, I want to say that the current implementation is really smooth and works great!
Is it possible to modify the middleware to initialize transactions lazily?
Ideally, the transaction would only start when GetTran is called (i.e., for handlers using .newWithTx).
This would avoid starting unnecessary transactions for endpoints that don't require them.
Any guidance or thoughts on implementing this would be greatly appreciated. Thanks!

[ardan-bkennedy]

If you only apply the middleware at the route level that would make it only applicable for that route.

Are you saying a given route may or may not need to be in a transaction?

[mscno]

I am using the middleware in a RPC based API. And most of the RPC frameworks (GRPC, ConnectRPC etc) make it tricky to define middleware at the route level, they typically only allow definition of middleware at the service level.
So in my case I have service A, which has methods M1 and M2, where M2 needs tx support, while M1 does not. Adding the middleware at service A, allows me to call .newWithTx() in M2 to dynamically swap the bus/stores with the tx backed versions and use the tx in ctx, by getting it with GetTran(). But for M1, where I dont use the tx object in ctx, I still start and commit an "empty transaction" for all method calls to M1 route, since the BeginCommitRollback middleware is registered at the service level.
It would be great to add conditional support for transactions, but only start the transaction once there is a call to GetTran()

[ardan-bkennedy]

My first thought is to somehow pass state to the Tx middleware function to just return or not. Maybe in the context. The problem is that middleware function will execute before the app layer function.

My next thought is maybe you have two different muxes handling traffic. The one that needs Tx and the one that don't. Then you can set different global middleware.

Then you have the mux that actually accepts the traffic. The handlers basically proxy one of the other two muxes.