A dependency walk that stopped at the first level of nesting filled a foreign-key column with NULLs

The referencing entity gets scheduled first, `zcategories` has not loaded, and its id_map is empty, so every lookup against it misses ^[10]. `on_missing: null` was written for the ordinary case where a source document was genuinely deleted ^[9]. It cannot tell that case from a target entity that has never loaded a single row, and the author is explicit that those are different failure modes ^[14].

Nothing downstream can see the difference. NULLs do not change row counts ^[11]. The dangling-reference check runs after the full migration, and by then `zcategories` has loaded, so it re-checks the references and finds nothing wrong ^[12].

It took both changes for the run to finish without an error. An empty id_map used to raise an unconditional `LoadError` and kill the run ^[8], so the same nesting-blind ordering fault would have been loud one version earlier ^[1].

The root-cause fix is one line of recursion, with `_explode_lookup_targets` unioning in its own result for each nested `explode` ^[15]. When `on_missing` is anything other than `ERROR`, the loader asks whether the target entity has any id_map rows at all, and raises `LoadError` when the answer is none ^[16]. Its message tells the operator to go looking for a load-order bug or a forgotten prerequisite run instead of a genuinely dangling reference ^[17]. Caching makes it cheap: one extra indexed query the first time a lookup to that entity misses, not one per row ^[18]. It also catches a prerequisite migration run that nobody ever executed, and correct ordering does nothing for that one ^[19].

The author first wrote this up as a one-off, and says two bugs since have changed that view ^[24]. "Two checks aimed at one mistake are one check," the author wrote ^[20]. The `--pg-schema` flag is the second case. It exists so you can migrate into a schema other than `public`, and it reached `introspect_postgres()` and nothing else ^[21]. Every write named its table unqualified, so rows landed wherever the connecting role's `search_path` pointed, normally `public`, and nothing errored ^[22]. Then `validate` counted those same wrong tables and printed `[OK] hospitals (hospitals): mongo=4002 postgres=4002` ^[23].

This is one developer's report on an alpha tool at v0.2.0 ^[1], and the two orderings are a repro, not a measured population ^[6]. The shape reaches your pipeline if the code that orders work and the code that validates configuration derive their view of the schema from the same traversal. A level that traversal never walks is then invisible to both, which is why a typo'd entity name in a nested lookup came back from validation with zero issues ^[7].