I do have to say that you just made a lot of suppressing just to ignore the warnings, which might introduce some non indicative NullReferenceExceptions. I believe the warnings should rather remind to us provide a different behavior when its actually null, or at least provide some information to the user (or logger).

I may have misunderstood the whole “nullables” concept, but from what I understand, they exist so developers can double check they indeed handle a possible null value properly before implementing it on a new system, and mark with “!” if they indeed did.

In reality, those values will NOT be null here based on all current implementations that the engine supports, and it doesn’t support alternative state loading ways in which these can be null.

Let me know if you have a different view on the nullables, or if you have an alternative way to propose that handles this — or if you wanna try your hand at it I’d be happy to learn how you’ll handle this!

I’m thinking more long-term. If the implementation ever changes, or someone modifies the state-loading logic in the future, we might suddenly start seeing NullReferenceExceptions in unexpected places.

As for this specific comment context, state.Embeds is of a non nullable type LLamaToken[] so I don't even think a suppression was necessary. As of state.InputPrefixTokens, if it can't be null in the current project implementation - why not just change its type to not nullable?

In general I agree with the inhouse double check approach you mentioned, I just hate to assume something will never happen so I made this comment because that was (almost) the only way you handled this warning across the PR, which made me wonder if a "double check" was made. Thank you for your contribution.