Spring proxies break @Workflow/@Step annotation discovery

[LuaKT]

Hi,
I'm hitting an issue with trying to use this when workflow impl classes are Spring proxied due to @Transactional on the methods in the class.

For example, a setup like this fails:

@Service
public class AccountSyncWorkflowImpl implements AccountSyncWorkflow {

    private AccountSyncWorkflow proxy;

    public void setProxy(AccountSyncWorkflow proxy) {
        this.proxy = proxy;
    }

    @Override
    @Workflow(name = "syncAccount")
    public void syncAccount(UUID accountId) {
        // workflow body...
    }

    @Transactional(readOnly = true)
    public void loadAccount(UUID accountId) {
        // db read
    }
}

@Configuration
public class AccountSyncWorkflowConfig {

    private final AccountSyncWorkflowImpl workflowImpl;

    public AccountSyncWorkflowConfig(AccountSyncWorkflowImpl workflowImpl) {
        this.workflowImpl = workflowImpl; // Spring-managed bean, proxied due to @Transactional
    }

    @Bean
    @Primary
    public AccountSyncWorkflow accountSyncWorkflow() {
        var proxy = DBOS.registerWorkflows(AccountSyncWorkflow.class, workflowImpl);
        workflowImpl.setProxy(proxy);
        return proxy;
    }
}

DBOS.startWorkflow(() -> accountSyncWorkflow.syncAccount(UUID.randomUUID()));

Will error with:

java.lang.RuntimeException: Only @Workflow functions may be called from the startWorkflow lambda
        at dev.dbos.transact.internal.DBOSInvocationHandler.invoke(DBOSInvocationHandler.java:60)
        at jdk.proxy3/jdk.proxy3.$Proxy116.syncAccount(Unknown Source)
...

The issue is that in DBOSInvocationHandler.invoke, getAnnotation is called on the proxy which doesn't have the annotation.

dbos-transact-java/transact/src/main/java/dev/dbos/transact/internal/DBOSInvocationHandler.java

Lines 49 to 58 in 7b8ee81

	public Object invoke(Object proxy, Method method, Object[] args) throws Exception {
	var implMethod = target.getClass().getMethod(method.getName(), method.getParameterTypes());
	implMethod.setAccessible(true);
	var hook = hookHolder.get();
	var wfTag = implMethod.getAnnotation(Workflow.class);
	if (wfTag != null) {
	return handleWorkflow(implMethod, args, wfTag, hook);
	}

I think instead the real class should be resolved and the annotation info cached when the workflow is registered, then in invoke it uses this cache instead of doing reflection on every invocation.

Thank you

[devhawk]

Thanks for opening this @LuaKT. We aren't well integrated into spring boot yet. Given its prominence in the java ecosystem, it's definitely something we are going to do.

[jonjanisch]

@LuaKT - I'm using Quarkus and not Spring, but it has a similar problem. The pattern I use is to not intermingle Workflow with other business logic (so no @Transactional annotations in a WorkflowImpl class). Then, I use a dedicated WorkflowSteps class that is @ApplicationScoped and can have @Transactional annotations. So each workflow has 3 classes:

• ExampleWorkflow (interface)
• ExampleWorkflowImpl
• ExampleWorkflowSteps

@Inject
ExampleWorkflowSteps steps;

@Workflow(name = "example-workflow")
@Override
public void runWorkflow() {
    DBOS.runStep(() -> steps.stepOne(), "stepOne");
    DBOS.runStep(() -> steps.stepTwo(), "stepTwo");
}

It adds an extra class, but will avoid issues with devs calling steps without using the proxy instance (and needing to explain the intricacies of the proxy instance).

I should add that our code is actually a bit different in that we use a wrapper over the DBOS instance for transactional steps. Our app is multi-tenant and we typically resolve the tenant from the request path. DBOS steps would run outside of the request scope in the case of retries, so we created some helper class to run steps within a Quarkus request context for a given tenant.

[devhawk]

FYI, we are moving to pure instance approach for DBOS (#306) which will make it easier for us to integrate into spring proxies. I have a prototype Spring aspect integration app you can check out https://github.com/devhawk/spring-aspect-demo, but note it uses features of DBOS that haven't been integrated into main yet so you won't be able to run it locally for a bit.

Presumably we'll be able to support Quarkus as well, but I haven't looked at that.

[jonjanisch]

I can share a Quarkus extension I created that may be a good starting point for something official. Quarkus extensions are a bit different than Spring. Quarkus moves all reflection to compile time to avoid scanning for annotations during prod application startup.

One of the cool things about the extension is it provides automatic registration with a single annotation provided by the extension. Here's a minimal example.

@DBOSWorkflow
public class ExampleWorkflowImpl implements ExampleWorkflow {

  @Workflow(name = "example-workflow")
  public void runWorkflow() {
     // .... normal workflow code
  }
}

This is almost a complete DBOS application (interface still needed). All the boilerplate of the registration process, launching, and shutting down DBOS is removed. The only other step is setting up the config in Quarkus's properties file:

quarkus.dbos.datasource.jdbc.url=jdbc:postgresql://localhost:5432/dbos_example
quarkus.dbos.datasource.username=postgres
quarkus.dbos.datasource.password=password
quarkus.dbos.conductor-key=dbos_12345
... etc

I was about to go crazy and remove the need for the interface, but that requires bytecode manipulation which I didn't really want to attempt. At first I thought having the singleton DBOS instance would be problematic. But in practice it hasn't caused any issues.

[devhawk]

I very much am interested in quarkus support. I've opened #308 to track that.