Problem
The Task<T> and CompletableTask<T> classes in packages/durabletask-js/src/task/task.ts and packages/durabletask-js/src/task/completable-task.ts are the foundational building blocks of the entire SDK. Every orchestration, activity, entity operation, timer, and sub-orchestration produces a Task or CompletableTask. Despite this, they have zero direct unit tests.
Currently they are only tested indirectly through when-all-task.spec.ts, when-any-task.spec.ts, and orchestration_executor.spec.ts. None of these files exercise the base class behavior in isolation.
Missing Coverage
Task<T> (base class)
getResult() throws "Task is not complete" when called before completion
getResult() re-throws the stored TaskFailedError when the task has failed
getException() throws "Task did not fail" on a non-failed task
isFailed correctly reflects state (false before failure, true after)
isComplete correctly reflects state
CompletableTask<T>
complete() throws "Task is already completed" on double-completion
fail() throws "Task is already completed" on double-failure
complete() after fail() throws (and vice versa)
complete() notifies parent via onChildCompleted()
fail() sets the exception as a TaskFailedError and notifies parent
fail() without explicit details creates a default TaskFailureDetails
Root Cause
These classes were written early in the project's lifecycle and their behavior was considered simple enough to test only through integration with composite tasks and the executor. As the SDK has grown, this gap has become more significant.
Impact
- Severity: Medium — the classes are simple but foundational. A regression here silently breaks everything above.
- Risk: Without isolated tests, changes to the base class behavior (e.g., adding new states, modifying completion semantics) could introduce subtle bugs that composite tests don't catch.
Problem
The
Task<T>andCompletableTask<T>classes inpackages/durabletask-js/src/task/task.tsandpackages/durabletask-js/src/task/completable-task.tsare the foundational building blocks of the entire SDK. Every orchestration, activity, entity operation, timer, and sub-orchestration produces aTaskorCompletableTask. Despite this, they have zero direct unit tests.Currently they are only tested indirectly through
when-all-task.spec.ts,when-any-task.spec.ts, andorchestration_executor.spec.ts. None of these files exercise the base class behavior in isolation.Missing Coverage
Task<T>(base class)getResult()throws"Task is not complete"when called before completiongetResult()re-throws the storedTaskFailedErrorwhen the task has failedgetException()throws"Task did not fail"on a non-failed taskisFailedcorrectly reflects state (false before failure, true after)isCompletecorrectly reflects stateCompletableTask<T>complete()throws"Task is already completed"on double-completionfail()throws"Task is already completed"on double-failurecomplete()afterfail()throws (and vice versa)complete()notifies parent viaonChildCompleted()fail()sets the exception as aTaskFailedErrorand notifies parentfail()without explicit details creates a defaultTaskFailureDetailsRoot Cause
These classes were written early in the project's lifecycle and their behavior was considered simple enough to test only through integration with composite tasks and the executor. As the SDK has grown, this gap has become more significant.
Impact