feat: Add configurable workflow status subscription for HTTP webhook publisher

[akhilpathivada]

Resolves #710

Summary

Enables configuration-based control over which workflow status changes trigger HTTP webhook events, matching the existing task status publishing behavior.

Problem

The HTTP webhook publisher (conductor.workflow-status-listener.type=workflow_publisher) currently hardcodes publishing only COMPLETED and TERMINATED workflow events, with no way to configure which statuses to receive. This is inconsistent with the task publisher which allows full configurability via subscribed-task-statuses.

Solution

Added subscribedWorkflowStatuses configuration property to enable selective workflow event publishing:

# New configuration property
conductor.status-notifier.notification.subscribed-workflow-statuses=RUNNING,COMPLETED,TERMINATED,PAUSED

# Valid values: RUNNING, COMPLETED, FAILED, TIMED_OUT, TERMINATED, PAUSED, RESUMED, RESTARTED, RETRIED, RERAN, FINALIZED

Changes

1. StatusNotifierNotificationProperties: Added subscribedWorkflowStatuses field with getters/setters
2. StatusChangePublisherConfiguration: Inject workflow status config and pass to publisher
3. StatusChangePublisher: Implement conditional checks in all 9 workflow lifecycle methods
4. StatusChangePublisherTest: Added comprehensive unit tests (17 test cases)
5. config.properties: Added configuration example with documentation

Testing

✅ All 9 workflow status methods tested with various configurations
✅ Null and empty list handling
✅ Build successful with no linter errors

[akhilpathivada]

@v1r3n @manan164 could you please help reviewing this?

[v1r3n]

Yes we are on it and should be part of next release if all looks good.

[manan164]

Backward Compatibility Issue

Problem: This PR introduces a breaking change for existing deployments.

Current Behavior (Before This PR)

@Override
public void onWorkflowCompleted(WorkflowModel workflow) {
    blockingQueue.put(workflow);  // ALWAYS publishes
}

COMPLETED and TERMINATED events are always published automatically with no configuration needed.

New Behavior (With This PR)

@Override
public void onWorkflowCompleted(WorkflowModel workflow) {
    if (subscribedWorkflowStatusList != null 
            && subscribedWorkflowStatusList.contains("COMPLETED")) {
        enqueueWorkflow(workflow);  // Only publishes if configured
    }
    // Otherwise: NOTHING happens
}

Events are only published if explicitly configured.

Breaking Scenario

Existing User:

1. Using HTTP webhook publisher: conductor.workflow-status-listener.type=workflow_publisher
2. Receiving COMPLETED and TERMINATED webhooks automatically
3. Their monitoring/integration relies on these webhooks

After Upgrading:

1. User doesn't set the new property (doesn't know it exists or thinks it's optional)
2. Spring injects subscribedWorkflowStatusList = null
3. Condition fails: null != null → false
4. NO webhooks are sent anymore ❌
5. User's monitoring breaks

Recommended Fix

Default to previous behavior when not configured:

public StatusChangePublisher(
        RestClientManager rcm,
        ExecutionDAOFacade executionDAOFacade,
        List<String> subscribedWorkflowStatuses) {
    this.rcm = rcm;
    this.executionDAOFacade = executionDAOFacade;
    
    // Preserve backward compatibility - default to COMPLETED and TERMINATED
    this.subscribedWorkflowStatusList = (subscribedWorkflowStatuses != null && !subscribedWorkflowStatuses.isEmpty()) 
        ? subscribedWorkflowStatuses 
        : Arrays.asList("COMPLETED", "TERMINATED");
        
    ConsumerThread consumerThread = new ConsumerThread();
    consumerThread.start();
}

This way:

• ✅ No config = keeps working (COMPLETED + TERMINATED)
• ✅ Empty list = opt-out (disable all)
• ✅ Custom config = opt-in to specific statuses

Also update the test testWithNullSubscribedList() to verify it publishes COMPLETED and TERMINATED by default.

---

Note: CI is failing on an unrelated flaky test (PostgresGrpcEndToEndTest). Suggest rebasing on main after PR #772 merges, which fixes the Docker Engine 29.1 incompatibility.

[akhilpathivada]

Hi @manan164 Thanks for the catch! Rebased with main and fixed -- null/empty list now defaults to ["COMPLETED", "TERMINATED"] to preserve backward compatibility.

Also, I noticed your comment mentions ✅ Empty list = opt-out (disable all)while the code snippet defaults empty list to COMPLETED/TERMINATED. I went with the code for now. If we'd prefer [] to act as an explicit opt-out instead, happy to adjust -- though users can already disable notifications entirely by removing conductor.workflow-status-listener.type=workflow_publisher from their config.

Open to your thoughts on this!