Fix NPE in FlinkStateSnapshot cleanup causing orphaned CRs and blocked namespace deletion

[Yanisdje]

Problem

When a FlinkStateSnapshot CR is deleted before the FlinkStateSnapshotController has reconciled it, cleanup() throws a NullPointerException on getStatus().toBuilder(). The status is null because the CR was never processed by reconcile() which is the only method that initializes it.

The NPE prevents the finalizer from being removed, causing the CR to be permanently stuck in a terminating state. This blocks namespace deletion and cluster migration. Observed in production with CRs stuck since October 2025.

Root Cause

FlinkStateSnapshot CRs are created without a status (the status subresource is only populated when reconcile() runs). If the CR receives a deletion timestamp before reconcile() runs, JOSDK calls cleanup() directly. reconcile() already has a null status guard:

// status might be null here
flinkStateSnapshot.setStatus(
        Objects.requireNonNullElseGet(
                flinkStateSnapshot.getStatus(), FlinkStateSnapshotStatus::new));

cleanup() and updateErrorStatus() are missing this guard, causing the NPE.

Fix

Add the same null-status initialization to cleanup() and updateErrorStatus(). A null-status snapshot was never triggered against Flink - no data exists on storage - so cleanup can safely proceed. For checkpoints (the observed case), cleanup immediately returns defaultDelete() via the isCheckpoint() check.

Impact

• Resolves all currently stuck FlinkStateSnapshot CRs on next operator retry cycle
• Unblocks terminating namespaces waiting on finalizer removal
• Prevents future orphaned snapshots from accumulating

[ryanvanhuuksloot]

This seems out of place.

[ryanvanhuuksloot]

Updating the status before the updateErrorStatus is strange.

[Yanisdje]

It was added as a guard since updateErrorStatus also calls getFlinkStateSnapshotContext(), which is where the NPE originates.

But the reconcil() method immediately initializes the status as its first action before anything can throw. So status will never be null when updateErrorStatus is called. So it makes sense to remove it. I will only keep the check above.