Summary
The current BaseCoordinator interface is tightly coupled to subprocess-based execution and socket communication (TCP or Unix Domain). As the coordinator pattern expands to support additional SDK implementations, the base interface should be abstract enough to accommodate alternative transport mechanisms without requiring subclasses to override low-level internals.
Problem
BaseCoordinator exposes implementation details specific to subprocess + socket IPC- Coordinators that could benefit from other communication channels (e.g. shared memory, in-process execution) have no clean abstraction to build against
- The current design makes it harder to reason about what is a required contract vs. what is a Java-specific detail
Proposed Changes
- Raise the abstraction level of
BaseCoordinator's public interface so that communication channel and process launching are not assumed
- The interface should be defined in terms of high-level operations (e.g. accepting a
DagFileParsingRequest and returning a DagFileParsingResponse) rather than prescribing how those operations are carried out underneath
- Concrete implementations such as
JavaCoordinator remain free to use subprocesses and sockets internally
Acceptance Criteria
BaseCoordinator public interface makes no assumptions about transport (sockets, shared memory, etc.) or process model (subprocess vs. in-process)- Existing
JavaCoordinator and Go SDK coordinator behavior is preserved
- A new coordinator implementation using a non-socket channel could be built against
BaseCoordinator without workarounds
Drafted-by: Claude Code (Opus 4.7); reviewed by @jason810496 before posting
Summary
The current
BaseCoordinatorinterface is tightly coupled to subprocess-based execution and socket communication (TCP or Unix Domain). As the coordinator pattern expands to support additional SDK implementations, the base interface should be abstract enough to accommodate alternative transport mechanisms without requiring subclasses to override low-level internals.Problem
BaseCoordinatorexposes implementation details specific to subprocess + socket IPCProposed Changes
BaseCoordinator's public interface so that communication channel and process launching are not assumedDagFileParsingRequestand returning aDagFileParsingResponse) rather than prescribing how those operations are carried out underneathJavaCoordinatorremain free to use subprocesses and sockets internallyAcceptance Criteria
BaseCoordinatorpublic interface makes no assumptions about transport (sockets, shared memory, etc.) or process model (subprocess vs. in-process)JavaCoordinatorand Go SDK coordinator behavior is preservedBaseCoordinatorwithout workaroundsDrafted-by: Claude Code (Opus 4.7); reviewed by @jason810496 before posting