I labelled a dependency cycle "unknown" and called it rigour
The article examines a common pitfall in continuous integration checks: labeling dependency cycles as UNKNOWN instead of FAIL. It explains why a third result value should represent undecidable outcomes, not ambiguous failures, and outlines how mislabeling can mask critical build issues. The piece c…
In continuous integration pipelines, a single mislabel can turn a broken build into a silent success. When a dependency graph contains a cycle, the system should report a clear failure. Yet some teams, including the author’s own, have mistakenly marked such cycles as UNKNOWN, effectively erasing a red flag from the build report.
What Happens When a Cycle Is Mislabelled?
A dependency cycle occurs when two or more components depend on each other, creating a loop that prevents the build system from determining a valid order of execution. In a correctly configured check, the system should detect the cycle and emit a FAIL status. Instead, the author’s team treated the cycle as an UNKNOWN result, a value reserved for situations where the tool cannot reach a conclusion—such as an unreadable file or a missing input.
By labeling the cycle as UNKNOWN, the build report no longer shows a red line. The summary line stops indicating that the build is broken, and developers are left unaware that a critical issue exists. This subtle shift can lead to cascading failures downstream, as the cycle remains unresolved until someone manually inspects the dependency graph.
Why a Third Value Is Needed, and Where It Goes Wrong
Testing frameworks traditionally use two verdicts: PASS and FAIL. A third value—UNKNOWN—is essential for situations where the tool cannot decide. Examples include:
- A file the reader cannot open.
- A rule whose input never arrived.
- A record produced by a person that cannot be re‑run.
These scenarios are inherently undecidable. A dependency cycle, however, is a concrete negative decision: the graph is not a Directed Acyclic Graph (DAG). The system has successfully traversed the graph and concluded that the cycle exists. Therefore, the correct verdict is FAIL, not UNKNOWN.
Root Cause: Misaligned Rank Calculation
The author discovered that the bug stemmed from how component ranks were calculated. The check compared each component’s declared rank against the order the blocks appear in the configuration file—a proxy for acceptance order. While this works when foundations are added first, it breaks when a file is reordered. The rank calculation inadvertently produced a third value (UNKNOWN) when a component’s dependency row had not yet been written, leading to a false sense of epistemic humility.
In practice, the algorithm looked like this:
- rank_source = position of the block in the file + 1
- rank_source = 1 + max(rank of everything in
stands_on)
When a component’s stands_on list referenced a block that was not yet parsed, the rank could not be derived, and the check returned UNKNOWN. This third value was then mistakenly applied to cycles, masking the real problem.
Correcting the Verdict Logic
The fix is straightforward: if the traversal completes and produces a negative answer, the verdict must be FAIL, regardless of how the user feels about it. UNKNOWN should only be used when the tool genuinely cannot reach a conclusion. By enforcing this rule, the build system will correctly flag cycles, and developers will receive the red line they need to act on.
Additionally, the author recommends adding a simple check: if (device_decided) then verdict = FAIL. This ensures that any negative decision is treated as a failure, not an escape hatch.
Implications for DevOps Practices
Mislabeling cycles as UNKNOWN can have far‑reaching consequences. Teams may deploy broken code, leading to runtime errors that are harder to trace. By maintaining a strict FAIL status for cycles, organizations preserve the integrity of their CI pipeline and reduce the risk of silent failures.
Moreover, this lesson underscores the importance of clear semantics in test verdicts. A third value should never be reachable from a state where the tool has successfully decided. When it is, the system is effectively providing an escape hatch, which defeats the purpose of automated checks.
In summary, dependency cycle detection should always yield a FAIL verdict. UNKNOWN is reserved for undecidable situations, and its misuse can hide critical build issues. By tightening the logic and understanding the underlying rank calculation, teams can ensure that their CI pipelines remain honest and reliable.
Why it matters
Accurate failure reporting is critical for maintaining the reliability of software builds. Mislabeling a dependency cycle as UNKNOWN can hide serious issues, leading to downstream bugs and costly rollbacks.
Key points
- Dependency cycles must be reported as FAIL, not UNKNOWN.
- UNKNOWN is reserved for undecidable outcomes like unreadable files.
- Misaligned rank calculations can produce false UNKNOWN results.
- A strict FAIL verdict ensures developers see critical build failures.
- Clear semantics in test verdicts prevent silent failures in CI pipelines.
Frequently asked questions
What is a dependency cycle?
A dependency cycle occurs when two or more components depend on each other, creating a loop that prevents the system from determining a valid build order.
Why should a cycle be marked as FAIL?
Because the system has successfully traversed the graph and determined that it is not a DAG; this is a concrete negative decision that must be reported as a failure.
When is UNKNOWN an appropriate verdict?
When the tool cannot reach a conclusion, such as an unreadable file, missing input, or a record that cannot be re‑run.
