Hi Dmitri, Thanks for the feedback.. Glad Option 1 looks reasonable.
I'll hold off on implementation until more folks weigh in, especially anyone with deep context on *legacy resolution paths.* If anyone wants to see a draft PR or specific files that'd change, let me know and I can put something up for review before we commit to the full cleanup. Looking forward to hearing from others. Thanks, Vignesh On Thu, 25 Jun 2026 at 08:01, Dmitri Bourlatchkov <[email protected]> wrote: > 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 > > >
