validate() scope violations omit the chain that reached the offending provider

[lesnik512]

Split out of the original bundled roadmap line (see #438). The binding half is now #468 and
is closed; this issue is the diagnostics half only, and the report its needs-info label was
waiting on is below.

The report

validate()'s scope check follows redirects to decide whether an edge is inverted
(terminal_scope in dependency_graph.py), then builds a message naming the declared dependency
beside the terminal's scope, and discards everything in between. Through an Alias — which is how
an abstract base or Protocol is bound to an implementation — those are two different providers, and
the one you have to change is named nowhere.

Handler at APP depending on Impl at REQUEST through a three-hop Protocol chain:

Container.validate() found 1 issue(s): InvalidScopeDependencyError

InvalidScopeDependencyError (1):
  - Provider Handler (scope APP) declares parameter 'svc' typed as a provider of IA at deeper scope REQUEST. A provider cannot depend on a deeper-scoped provider.

IA is the Protocol and declares no scope at all. REQUEST belongs to Impl. Impl does not
appear, and it is not recoverable in code either: .dep_provider is the alias and its source type is
private, so the fact is absent from the message and from the attribute surface.

Resolving the same graph, rather than validating it, prints this:

Cannot resolve dependency chain:
  APP      Handler (app:8)
  APP      └─> IA
  APP          └─> IB
  APP              └─> IC
  REQUEST              └─> Impl (app:7)
  caused by: Provider of scope REQUEST cannot be resolved in container of scope APP.

Why this is not "the wording could be better"

Per ADR 0009,
a message that reads awkwardly is not a defect. Three things here are more than that:

1. A sibling error out of the same walk already does it right. A cycle through the same alias
   renders the full arrow tree with declaration sites, because build_cycle_error keeps the
   providers it walked. Two errors from one validate() call, one drawing the chain and one printing
   a line, is the drift the shared _render_chain exists to prevent.
2. The fact is missing from the attributes, not just the text. That is ADR 0009's own revisit
   trigger, one step earlier: there is nothing to parse out of str(exc) because the terminal is not
   in the string.
3. validate(), whose only job is diagnosis, prints strictly less than the crash it exists to
   prevent. Even with no alias involved this error carries no module:line for either provider,
   while every other chain-shaped error does.

Also note the runtime tree above draws APP for IA, IB and IC. Alias sets
_takes_group_scope = False and passes scope=UNSET, so AbstractProvider.scope returns the
Scope.APP default for every alias — a band nothing in the graph chose. CircularDependencyError
prints the same fiction today.

Resolution

Implemented on fix/scope-violation-chain, recorded as ADR 0029:

• the redirect walk keeps its chain (terminal_chain()), rather than discarding it to return a scope;
• InvalidScopeDependencyError renders through _render_chain like its three siblings, and gains
  .dep_chain with .dep_provider / .dep_terminal as its ends;
• each redirect hop draws at the scope it resolves at, so the APP/REQUEST boundary lands on the
  offending edge. Alias.scope still returns APP; scope ordering depends on it, so this is a
  rendering rule, not a change to the provider.

The same graph now renders identically from both detectors:

InvalidScopeDependencyError (1):
  - Provider at a deeper scope reached through this chain:
      APP      Handler (app:8)
      REQUEST  └─> IA
      REQUEST      └─> IB
      REQUEST          └─> IC
      REQUEST              └─> Impl (app:7)
      caused by: Handler (scope APP) declares parameter 'svc' typed as a provider of Impl at deeper scope REQUEST. A provider cannot depend on a deeper-scoped provider.

Guarded by an invariant test that validate() and a runtime resolve name the same chain, an
attribute test that the terminal is recoverable without parsing the message, and a rendering test
that the alias hop draws REQUEST while its own .scope is APP.

[lesnik512]

This was generated by AI during triage.

Triage outcome: needs-info

Relabeling needs-triage → needs-info. #446 authored this with its reasoning and revisit trigger already in place; what it waits on is a concrete report, not a maintainer decision.

What is established:

• The diagnostics described as "already exist" do exist. Container.validate() is at modern_di/container.py:273. modern_di/exceptions.py carries the full hierarchy — DependencyPathMixin renders the arrow-tree chain, with ScopeSkippedError, ScopeNotInitializedError and CircularDependencyError on top of it. modern_di/suggester.py produces the "did you mean" suggestions via difflib, capped at three.
• The binding half is settled, not open. ADR 0025 fixes what Alias is and is not; re-proposing it as a binding mechanism is closed. ADR 0018 separately declined a static wiring checker, so the answer cannot be "verify it ahead of time".
• Error text is not a contract. ADR 0009 means a proposal to change these messages is free to do so, but also that "the wording could be better" is not by itself a defect.

What would move it:

• A specific graph whose scope- or cycle-violation message left you unable to find the offending edge — the graph, the message it produced, and the edge you were looking for.
• Or a binding case the current primitives cannot state at all, as opposed to state awkwardly.

Two rough edges are bundled here under one roadmap line. If a report arrives for only one of them, it is worth splitting rather than actioning both.

[lesnik512]

Split done: the binding half moved to #468 and is closed against ADR 0025 and ADR 0018. This issue is now the diagnostics half only, retitled to name the actual defect, and the body carries the report needs-info was waiting on. Relabelled needs-info -> ready-for-human.

Two things worth flagging beyond the original complaint, both found while reproducing it:

• The gap is not really validate() versus runtime. It is within one validate() call: CircularDependencyError and InvalidScopeDependencyError come out of the same _walk_errors loop, and only one of them draws the chain.
• The APP band the runtime tree prints for alias hops is a default Alias never chose, and CircularDependencyError prints it too. Fixed in the same change rather than left for later, since both errors read through the same drawer.

Implementation is on fix/scope-violation-chain with ADR 0029; no PR opened yet.