Upstream issue candidates from waves B, D and E

Purpose

Collects upstream-issue candidates surfaced during garden waves B (GDN-NOTE-0039), D and E (GDN-NOTE-0043) so a human can review and file them upstream. Each candidate lists evidence paths and ready-to-paste issue text. Nothing here has been filed; all claims verified against the working tree at vespa on 2026-10-28.

Wave coverage note: at write time /tmp/garden-waves contained only wave-a (GDN-NOTE-0036/0037/0038), wave-b (GDN-NOTE-0039) and wave-c (GDN-NOTE-0040). Wave-A and wave-C open questions are internal research questions, not upstream defects; no issue candidates came from them. Wave-D artifacts were not present on disk; candidates below are therefore from waves B and E only.

Candidate 1: stale README claim about ApplicationStatus

• Evidence: vespa/container-search-and-docproc/README.md line 7 says “This modules also contains the ApplicationStatus handler”, but the module has no src/ (tree contains only CMakeLists.txt, OWNERS, README.md, pom.xml). The handler actually lives in container-disc: com.yahoo.container.handler.observability.ApplicationStatusHandler (container-disc/src/main/java/com/yahoo/container/handler/observability/ApplicationStatusHandler.java:52), wired by config-model ContainerCluster.java:128 and 260-266 with the comment “null bundle, as the handler is in container-disc”.

• Severity: docs-only; misleading for anyone looking for the handler code in the README’s module.

• Suggested issue text:

  Title: container-search-and-docproc README claims it contains the ApplicationStatus handler
  Body: README.md line 7 states “This modules also contains the ApplicationStatus handler.” The module has no Java sources (it is a source-less container-plugin that merges container-search, docproc and searchlib into one bundle). The handler is com.yahoo.container.handler.observability.ApplicationStatusHandler in container-disc, wired by the config model (ContainerCluster#addApplicationStatusHandler). Please drop or correct the README sentence (also fixes the grammar “This modules”).

Candidate 2: test scaffolding baked into the production di.Osgi interface

• Evidence: vespa/container-disc/src/main/java/com/yahoo/container/di/Osgi.java carries its own TODO on line 17 (“remove test code from this interface”): default resolveClass (lines 53-59) does Class.forName, and default getBundle (lines 61-63) returns a MockBundle (import line 7). All other methods are silent no-op defaults.

• Severity: low; production behavior is fine because the only production subclass overrides these (HandlersConfigurerDi.ContainerAndDiOsgi via OsgiImpl), but the defaults silently degrade to classpath loading if a new implementation forgets to override.

• Suggested issue text:

  Title: container-disc: move test defaults (MockBundle, Class.forName resolveClass) out of the di.Osgi interface
  Body: com.yahoo.container.di.Osgi has default methods meant for testing only, per its own TODO comment. Extract them into a test-only base class or test implementation so production implementations cannot accidentally inherit classpath-resolution behavior.

Candidate 3: small TODO/ naming debt in the DI graph code

• Evidence: (a) HandlersConfigurerDi.java:45 “//TODO: rename” on a class named HandlersConfigurerDi that actually orchestrates the whole component-graph lifecycle and bundle installs, not just handlers; (b) ComponentNode.java:58 constructor parameter Annotation XXX_key with ”// TODO expose key, not javaAnnotation”; (c) ComponentGraph.java:214 “//TODO: don’t mutate nodes here.” where getComponentRegistry adds ComponentRegistryNode entries to the graph during complete().

• Severity: cosmetic/maintainability; no behavior claim.

• Suggested issue text:

  Title: container-disc DI: rename HandlersConfigurerDi, expose component key properly, avoid mutating graph during complete()
  Body: Three related TODOs in the component-graph package: HandlersConfigurerDi carries a “TODO: rename” and now owns the full DI lifecycle; ComponentNode has an XXX_key constructor parameter with a TODO to expose the key; ComponentGraph#getComponentRegistry mutates the node map during complete() (its own TODO flags this). Cleanup candidate for the DI maintainers.

Candidate 4: OsgiWrapper default getBundle returns null

• Evidence: vespa/container-disc/src/main/java/com/yahoo/osgi/OsgiWrapper.java:12-15 overrides the composite interface’s getBundle with return null; as a default.

• Severity: very low; a silent null default on a bridge interface can mask missing overrides. Possibly folded into candidate 2’s cleanup.

• Suggested issue text:

  Title: OsgiWrapper#getBundle default returns null
  Body: The OsgiWrapper bridge interface (com.yahoo.osgi.OsgiWrapper) overrides getBundle(ComponentSpecification) with a null default. Consider throwing UnsupportedOperationException instead so missing overrides fail loudly.

Non-candidates (checked, no issue)

• di.Container treating the topological sort as deconstruction order while construction is lazy via Node.component(): intentional design, consistent across Node.java:42-56 and ComponentGraph.java:168-173; not flagged.
• ConfiguredApplication binding a restricted DisableOsgiFramework for application code while HandlersConfigurerDi gets the real OsgiFramework: deliberate privilege split (ConfiguredApplication.java:165,451-466); not flagged.

Filing checklist (for the human)

1. Re-run the evidence paths against the current vespa.ai GitHub main; line numbers above reflect the local checkout of 2026-10-28.
2. Search the upstream tracker for existing issues mentioning “ApplicationStatus README” and “di.Osgi TODO” before filing.
3. Candidates 2, 3 and 4 could be combined into one “DI interface hygiene” issue if upstream prefers fewer, broader reports.