The release job timed out after partial adoption

Understand the likely causes

• The client can lose its response or stop waiting after the target accepts work. Canceling the client does not universally cancel target-side operations. A job that bundles submission, convergence, health checks, and reporting obscures the exact incomplete boundary.
• Concurrent requests, mutable candidate selection, non-idempotent retries, and absent operation identities can turn uncertainty into conflicting changes. State incompatibility may also make a familiar rollback candidate unsafe despite its retained package.

Preserve scope and establish ownership

Identify the target, candidate, configuration, operation identity if available, and first timeout timestamp from retained records. Notify the responsible incident or release owner through the established process; this guide does not send messages or perform operational actions. Avoid repeated reruns while completion is unknown. A single failed CI status should not be translated into an assumption that no external effect occurred.

Read the authoritative operation state

Use the owner’s approved read path to determine whether the original operation is absent, accepted and running, completed, failed, or unknown. Compare desired and observed candidate identities across the relevant instances. Keep telemetry failure separate from application failure. The following table distinguishes possible next decisions without prescribing a live command.

absent -> consider a new authorized request
running -> observe or use supported cancellation policy
completed -> continue verification and evidence publication
failed or mixed -> evaluate compatible recovery
unknown -> preserve uncertainty and investigate

Reuse intent rather than inventing another one

If the target supports idempotency, retain the same operation identity for a retry of the same intent. Do not change candidate or target under that identity. If deduplication is unavailable, inspect state and choose a controlled action with the owner rather than assuming a second request is harmless. Recheck freshness before any waiting request proceeds, because another valid release may already have adopted a newer candidate.

Choose a compatible outcome

A partial rollout may be completed, paused, or recovered depending on user impact and state compatibility. Review schema, queues, external actions, and configuration before selecting an older package. Reversing traffic does not undo completed business actions. Keep the scope narrow: a report failure after healthy adoption may require only evidence publication, while mixed application health can require an incident decision. Separate those cases instead of retrying the entire job.

Close the evidence gap

Retain the original request, observed transitions, decision authority, final candidate and configuration, and user-level verification. Record which job phases completed and which were resumed. The final result should explain why a failed CI job coexists with a successful target adoption when that occurred. This prevents a later reviewer or automation from treating the old failed status as a request to repeat already completed work.

Keep it from recurring

• Split submission, convergence, user verification, and reporting into visible states. Use stable operation identities and target-specific concurrency, retain candidates and compatibility evidence, and define timeout and cancellation semantics before release. Rehearse lost-response and partial-completion cases using offline models or an explicitly authorized disposable environment.