What are the most common ways affected-detection-based CI goes wrong in production, and how do these failures typically show up — as a build error, or as something worse?

## Why these failures are dangerous Affected-detection failures are dangerous precisely because most of them don't look like failures at all — CI reports green, the PR merges, and the breakage surfaces somewhere else, later, and more expensively. Understanding the specific mechanisms behind this is what separates someone who's read about affected detection from someone who's operated it. ## The false negative — a missing edge The most consequential failure mode is the **false negative**: the dependency graph the tool relies on doesn't contain an edge that exists in reality. Static-analysis-based graphs (built by parsing import/require statements) are blind to dynamic and runtime couplings: - reflection-based dependency injection that resolves a class by string name; - a plugin loaded via a path read from a config file at runtime; - a service that reads another project's output file from a shared filesystem location; - two services coupled only through a database schema or message-queue contract with no code-level import between them at all. When one of these hidden edges exists and the upstream side changes, the downstream consumer never enters the affected set, its tests never run, and CI reports green on a change that will break that consumer the moment it deploys. This is the textbook 'CI green, prod broken' incident, and postmortems for it almost always trace back to exactly this gap between the declared/inferred graph and actual runtime coupling. ## Base-commit miscomputation A second class of failure is base-commit miscomputation. If the diff is computed against the wrong reference — the current tip of a fast-moving target branch instead of the merge-base, or a stale cached 'last known good' commit that's actually several merges behind — the resulting changed-file set is wrong, and everything downstream (project mapping, traversal) inherits that error. In a merge-queue setup specifically, if two PRs land close together and each PR's affected computation only considers its own diff without accounting for the other PR's concurrent changes, an interaction bug between the two changes can slip through because neither PR's affected set, computed in isolation, covers the combination. ## Where the project boundaries are drawn A third failure mode sits in how project boundaries are drawn. - **Drawn too coarsely.** If a monorepo defines projects too coarsely — say, one giant 'backend' project covering a dozen logically separate services — affected detection can't discriminate between them, so any change anywhere in that blob marks the whole thing affected, defeating the purpose of scoping (this shows up as 'affected detection barely saves any CI time' rather than as an incident, since it's a false positive problem, not a false negative one). - **Drawn too finely.** Conversely, splitting boundaries too finely without carefully declaring every cross-boundary dependency increases the surface area for missed edges — more, smaller projects means more inter-project relationships that all need to be captured accurately, and any one gap reproduces the false-negative failure above. ## Graph staleness A fourth, more operational failure mode is graph staleness: if the dependency graph itself is cached and the cache-invalidation logic has a bug, the graph used for a given CI run can reflect an older state of the codebase than the diff being evaluated, causing recently added or removed dependency edges to be ignored during traversal. ## Mitigations Mitigations cluster around acknowledging that the graph is a model, not a proof. 1. Teams add explicit **'implicit dependency' declarations** for known-but-invisible couplings (Nx's `implicitDependencies` in `nx.json`, or equivalent constructs elsewhere) whenever they know a hidden edge exists, rather than hoping static analysis finds it. 2. They tag especially risky or foundational projects as **'always run,'** bypassing affected scoping entirely for the highest-blast-radius code. 3. And critically, they don't treat affected-only CI as the sole safety net forever — a nightly or pre-release **full build/test run** across every project acts as a backstop that will eventually catch a false negative that slipped through PR-time CI, even though it does so with much higher latency than the fast-path affected run. Organizations operating monorepos at scale (this pattern is well documented from companies like Google) treat the combination of fast, scoped, imperfect PR-time checks plus slower, exhaustive, periodic checks as the actual reliability story — neither one alone is sufficient.