[BUG] codepipeline: RetryStageExecution is a silent no-op that returns success (no stage is re-run)

What's wrong

codepipeline retry-stage-execution returns a success response and does nothing. No stage is re-run, no action is dispatched, no CodeBuild is started. The caller cannot distinguish this from a retry that was accepted and is in progress.

Reproduction

Against a pipeline with a failed stage (AWSAccelerator-Pipeline, Logging stage failed under execution 28d08c7e-ff64-425c-bb66-a38c766e1db0):

aws --endpoint-url http://localhost:4566 --region us-east-1 codepipeline retry-stage-execution \
  --pipeline-name AWSAccelerator-Pipeline \
  --stage-name Logging \
  --pipeline-execution-id 28d08c7e-ff64-425c-bb66-a38c766e1db0 \
  --retry-mode FAILED_ACTIONS

Response:

{
    "pipelineExecutionId": "28d08c7e-ff64-425c-bb66-a38c766e1db0"
}

That is a well-formed success. But floci's own log shows the request arrived exactly once and produced no work:

1 codepipeline action: RetryStageExecution

For the following several minutes the only subsequent activity is the caller's own polling (GetPipelineState, ListPipelineExecutions). There are no Started container lines, no CodeBuild invocation, and no stage transition. Polling get-pipeline-state continues to report the Logging stage unchanged.

Why it matters

A silent no-op that returns success is worse than an unimplemented operation that returns an error. Any tooling that retries a failed stage — including operators working a pipeline by hand — will conclude the retry was accepted and then wait indefinitely for a stage that was never restarted. In our case it cost a full diagnostic cycle before the log made clear that nothing had been dispatched.

Real CodePipeline re-runs the failed actions of the named stage and moves the stage back to InProgress.

Suggested fix

Either implement the operation (re-dispatch the stage's failed actions and transition the stage to InProgress), or — if it is out of scope for now — return UnknownOperationException / a clear unsupported-operation error so callers fail fast instead of waiting on work that will never happen. The second option is cheap and removes the trap immediately.

Possibly related

While confirming the above, get-pipeline-state reported None for the latestExecution.status of every stage, including stages that had definitively Succeeded and the Logging stage that had Failed, while list-pipeline-executions correctly reported the execution as Failed. If terminal per-stage state is not retained after an execution finishes, that is a separate fidelity gap in the same API and would also mislead an operator reading stage state. Filed here as an observation rather than a separate issue since it surfaced in the same call path; happy to split it out.