enrichWithJvmSamePackageDependents in packages/parser/src/dependency-analyzer.ts only fires when symbol is undefined AND the import graph found literally zero dependents (mirroring the C#/Go recovery tiers' precondition). That gate predates #1111, which made the JVM same-package index build-once-per-batch via RecoveryIndexes — the original cost argument for "only ever try this as an expensive last resort" is largely gone now.
#1005 Phase 2 Item 1 (see that PR) added an additive same-package tier to the call-graph (dependency-graph.ts's getCallers), which fires unconditionally for any JVM type-symbol query regardless of whether the import graph already found something — deliberately NOT mirroring findDependents's zero-only gate, because the two mechanisms' preconditions are exact inverses by design (see that PR's AC6).
Worth asking: should findDependents's file-level recovery become additive too (recover same-package dependents even when the import graph already found some), now that the cost argument for "only as a last resort" is weaker? This is a policy question with real trade-offs (e.g. dependentCount/riskLevel semantics for get_dependents, and whatever #1057's dependent-attribution-incomplete caveat wiring assumes about the zero-only precondition) — filing to track the question, not proposing an immediate answer.
enrichWithJvmSamePackageDependentsinpackages/parser/src/dependency-analyzer.tsonly fires whensymbolis undefined AND the import graph found literally zero dependents (mirroring the C#/Go recovery tiers' precondition). That gate predates #1111, which made the JVM same-package index build-once-per-batch viaRecoveryIndexes— the original cost argument for "only ever try this as an expensive last resort" is largely gone now.#1005 Phase 2 Item 1 (see that PR) added an additive same-package tier to the call-graph (
dependency-graph.ts'sgetCallers), which fires unconditionally for any JVM type-symbol query regardless of whether the import graph already found something — deliberately NOT mirroringfindDependents's zero-only gate, because the two mechanisms' preconditions are exact inverses by design (see that PR's AC6).Worth asking: should
findDependents's file-level recovery become additive too (recover same-package dependents even when the import graph already found some), now that the cost argument for "only as a last resort" is weaker? This is a policy question with real trade-offs (e.g.dependentCount/riskLevelsemantics forget_dependents, and whatever#1057's dependent-attribution-incomplete caveat wiring assumes about the zero-only precondition) — filing to track the question, not proposing an immediate answer.