-
Notifications
You must be signed in to change notification settings - Fork 223
Closed
Labels
kind/bugSomething isn't workingSomething isn't working
Description
When using the Dapr Workflow API directly in a Spring Boot application, the workflow fails with a NullPointerException
when attempting to start a workflow via the standard Dapr Workflow API endpoint. This creates an inconsistent experience compared to other Dapr users who can start workflows with a simple curl command. This issue was confirmed with the /start
, but likely applies to all workflow API endpoints.
Error:
io.dapr.durabletask - The orchestrator failed with an unhandled exception: java.lang.NullPointerException: Cannot invoke "io.dapr.durabletask.TaskOrchestrationFactory.create()" because "factory" is null
Current Behavior
- Users must implement custom REST controllers as a workaround
- The
@EnableDaprWorkflows
annotation does not resolve the issue - No clear documentation or standalone examples exist for Spring Boot workflows integration
- All workflow operations (not just starting workflows) are affected by this issue
Expected Behavior
- Spring Boot applications should be able to use the Dapr Workflow API directly, just like any other Dapr application
- A simple curl command should work to start workflows
- The experience should be consistent across all Dapr users
Architectural Incompatibility
The issue stems from timing and lifecycle management differences between Spring Boot and Dapr Workflow API:
-
Lifecycle Management
- Dapr Workflow API: Assumes workflow registration is complete before API operations are called
- Spring Boot: Initializes components during context startup
- No mechanism exists to know when the runtime is ready to handle operations
-
Registration Timing
- Dapr Workflow API: Requires workflows to be registered before any operations
- Spring Boot: Registers workflows during context initialization
- API calls may occur before registration is complete
-
Context Dependencies
- Dapr Workflow API: Expects a fully initialized workflow runtime
- Spring Boot: Initializes components during context startup
- The workflow runtime may not be ready when API calls are made
Current Workaround
Users must implement a custom REST controller to start workflows:
@RestController
public class WorkflowController {
@Autowired
private DaprWorkflowClient workflowClient;
@PostMapping("/start")
public ResponseEntity<String> startWorkflow(@RequestBody String requestBody) {
String instanceId = workflowClient.scheduleNewWorkflow(
LoanApplicationProcessing.class,
requestBody
);
return ResponseEntity.ok(instanceId);
}
}
Impact
- This architectural incompatibility affects all Spring Boot applications using Dapr Workflows
- Forces developers to implement workarounds instead of using standard Dapr patterns
- Increases maintenance complexity and reduces code clarity
- Creates inconsistency in how workflows are started across different Java applications
- No clear documentation or examples exist in the Dapr Java SDK
- Requires custom implementations for all workflow operations (start, terminate, get status, raise events, etc.)
This affects the ability to use Dapr Workflows in a standard way across different Java applications
Proposed Solutions
- Add clear documentation about this incompatibility
- Provide working Spring Boot workflow examples in the Dapr Java SDK
- Update Dapr documentation to clarify Spring Boot integration requirements
- Implement proper integration between Dapr Workflows API and Spring Boot apps
- Ensure consistent behavior across all Dapr APIs in Spring Boot
Related Documentation
- Current Dapr Workflow documentation does not adequately address Spring Boot integration
- No clear/standalone examples exist in the Dapr Java SDK for Spring Boot workflow implementation
Metadata
Metadata
Assignees
Labels
kind/bugSomething isn't workingSomething isn't working