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
