CI/CD / Editorial solution guide

The pipeline is green but the wrong candidate is observed

Trace source, package selection, configuration, and target observations before rebuilding anything.

About 3 min readContent reviewed

Read-only knowledge base · No public comments

Recognize the symptoms

The integration pipeline succeeds, but a synthetic Parcel verification reports behavior associated with an earlier revision. Another environment may show the expected behavior even though both jobs display the same friendly package name.

The deployment record names the intended candidate, while one or more runtime observations name another candidate or omit identity entirely. A successful upload or accepted request alone does not resolve this discrepancy.

Understand the likely causes

  • A consumer may select the newest successful job artifact instead of the explicitly approved candidate, or rebuild with different inputs after tests. Mutable package names can conceal different bytes.
  • Other possibilities include the wrong target, an old instance remaining during partial adoption, stale user-facing cache content, or configuration selecting an older code path. These hypotheses require different evidence and should not be collapsed into a generic cache problem.

Preserve the identity chain

Record the event and immutable revision under test, producer invocation, package digest, approval target, configuration revision, and observed runtime identity. Use existing authorized records and redact unrelated environment details. If a field is absent, mark it unknown rather than reconstructing it from a branch name that may have moved. The chain below is a diagnostic map, not proof that any particular platform already retains these relationships.

text A candidate relationship map
tested revision -> producer invocation -> package identity
package identity + configuration -> approved target
approved target -> observed instance identities

Every arrow needs evidence. A package filename, job name, or green badge is insufficient to prove the relationship. The map does not query or modify a delivery system.

Inspect how the consumer selects content

Read the release definition and retained selection record. Look for latest, branch-based, timestamp-based, or unqualified artifact searches. Confirm that the downloaded bytes match the candidate approved for that target. If promotion rebuilds the application, compare its actual inputs and evidence rather than assuming source equality implies package equality. Preserve the mismatching candidate for investigation; replacing it immediately can erase the clearest explanation.

Verify destination and configuration

Compare the intended environment with the resolved target through the owner’s approved observation path. A staging job can accidentally hold a production-like name, and the same package can select different behavior under a feature flag. Inspect configuration identity without dumping secrets. Determine whether the discrepancy affects every instance or only a subset before choosing a package, configuration, routing, or cache hypothesis.

Repair the broken relationship narrowly

Change the selection or promotion definition so it uses a specific verified candidate and records configuration separately. If adoption was partial, involve the target owner to decide whether to complete, stop, or recover it. Do not reissue a release blindly while an earlier operation may still be running. A rebuild is appropriate only when the candidate itself is wrong and a new candidate can pass the required contract.

Verify the fix

In an authorized lab or through existing operational evidence, compare expected and observed immutable identities for the relevant instances and configuration. Then check the affected user journey. Preserve the before-and-after chain; matching labels alone is weaker than authenticated package identity. This guide performs no deployment or live target inspection.

Keep it from recurring

  • Pass candidate identity explicitly, retain release packages independently of disposable caches, bind approvals to the candidate and target, and make application version observations available without exposing sensitive data. Test the selection path with two synthetic candidates so a mutable latest lookup cannot silently pass review.

Official references