Step Functions StopExecution: ABORTED Status Without Guaranteed Resource Termination

Stopping a Standard workflow execution via StopExecution changes the execution status to ABORTED and blocks new state transitions. The unresolved behavior is whether already-running service integrations terminate at that point or continue until they complete or fail independently. Task-level TimeoutSeconds and HeartbeatSeconds are documented as state-machine timers that limit how long a state waits for a result, but they do not appear to forcibly cancel the underlying AWS resource, such as a Lambda invocation, container task, or HTTP worker.

This distinction matters most for .sync service integrations, where the state waits for a backend job to reach a terminal state. If the parent execution is stopped while a .sync job is running, the backend job may remain active unless the specific integration propagates the cancellation signal. Because cancellation support is version-sensitive and varies by integration type, teams cannot assume a uniform behavior across services.

Does StopExecution reliably terminate in-flight .sync jobs in Standard workflows, or does it only prevent subsequent state transitions? Which service integrations currently support cancellation propagation to the underlying resource, and where is that behavior documented? What pattern bounds the lifetime of the backend job itself rather than only the state-machine timer?