Files
zeekayandHanzo Dev 5b8400410d the task activity's three outcomes are pinned
ExecuteTaskActivity is the seam between the durable queue and whatever actually
does the work, and none of its three paths was covered.

The one worth stating is the first: with no executor registered the activity
COMPLETES the task with an acknowledgment rather than failing it. That is the
right call — a task submitted to a deployment running no worker should not retry
forever against something that will never run it — but it means "completed" can
mean "nobody did this", and a test that says so out loud is cheaper than working
that out from a dashboard.

The other two are the pass-through and the failure: the executor's own result is
returned unchanged rather than the task the activity was handed, and a failure
yields NO task plus an error wrapping the cause. Returning the input task beside
an error would record work that never ran as work that did.

taskExecutor is package state, so the helper here saves and restores it; a test
that leaks an executor changes every test that runs after it.

Verified by breaking both compiling ways — returning the task beside the error,
and %w -> %v — each caught by the assertion written for it.

plugins/tasks 36.2% -> 37.9%.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-24 10:41:01 -07:00
..