Hi Vignesh, Thanks for starting this thread.
You proposed Option 1 sounds good to me. I hope other community members respond too. Broader community participation is essential to avoid surprises here as old polaris-core code affected by this discussion may have use cases that are not obvious to everyone. Thanks, Dmitri. On Mon, Jun 22, 2026 at 3:30 AM <[email protected]> wrote: > Subject: [DISCUSS] Nullability in PolarisResolutionManifest -- broader > cleanup? > > Hi all, > > During the review of PR #4825 [1], dimas-b raised a good point: > small incremental null guards in narrow sub-cases risk unknown > regressions. He suggested a broader cleanup of value availability > and nullability across the resolution code would be cleaner. > > The immediate issue: PolarisResolutionManifest has @Nullable getters > (getResolvedRootContainerEntity, getResolvedTopLevelEntity) that are > used in multiple call paths. Some callers guard against null, others > don't, leading to potential NPEs like List.of(null) when resolution > fails but code continues to use the manifest. > > I'm wondering what the preferred direction is here: > > 1. Make root getters @NonNull, fail fast. Callers must check > isResolveAllSucceeded() first. Cleanest but needs an audit. > > 2. Keep @Nullable with null-safe wrappers. Matches what > getResolvedTopLevelEntity already does. Safer but may silently > ignore missing roots. > > 3. Hybrid: root is @NonNull (fundamental), nested stays @Nullable. > Pragmatic middle ground. > > My preference is Option 1, but I'm happy to do the implementation > work once we agree on direction. > > Thoughts? > > [1] https://github.com/apache/polaris/pull/4825 >
