Python SDK workers cannot pick up tasks from workflows created in UI without domain configuration #348
Description
The Python SDK defaults CONDUCTOR_WORKER_DOMAIN to "default_domain" (self.domain = domain or os.getenv("CONDUCTOR_WORKER_DOMAIN", "default_domain")) instead of None , causing workers to poll from domain-specific queues (default_domain:taskType) while tasks created from the UI without taskToDomain configuration are queued in the default queue (taskType). This results in a confusing user experience where newly created workflows appear to hang with no workers picking up tasks.
When using the Python SDK with default configuration:
Workers poll with domain=default_domain parameter (e.g., /tasks/poll/my_task?workerid=worker1&domain=default_domain)
This polls from queue: default_domain:my_task
Meanwhile, workflows started via UI (without explicit taskToDomain configuration) schedule tasks with null domain
These tasks are queued in: my_task (no domain prefix)
Result: Workers never see the tasks, workflows appear stuck
Expected Behavior
The Python SDK should default to None for CONDUCTOR_WORKER_DOMAIN, making it consistent with:
The Conductor server's behavior (tasks without domain go to default queue)
The Java SDK's behavior (no domain unless explicitly configured)
User expectations (workers should work "out of the box" with UI-created workflows)
Steps to Reproduce
Start Conductor server
Create a workflow definition via UI with a simple task (e.g., my_task)
Start the workflow via UI without specifying taskToDomain in the Workbench
Observe in UI: task shows "Domain: (No Domain Set)"
Start a Python SDK worker for my_task with default configuration
Observe: Worker never receives the task
Proposed Solution
Change the default value of CONDUCTOR_WORKER_DOMAIN from "default_domain" to None in the Python SDK configuration: https://github.com/conductor-oss/python-sdk/blob/main/src/conductor/client/configuration/configuration.py#L190 .