.Net: Validate step types

[westey-m]

Motivation and Context

Description

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
• All unit tests pass, and I have added new tests where possible
• I didn't break anyone 😄

[Copilot]

Pull request overview

This PR strengthens runtime and builder-side validation to ensure only valid KernelProcessStep (and step state) types are accepted/loaded, improving safety when building processes and when restoring steps from Dapr-persisted state.

Changes:

• Add type validation in ProcessStepBuilderTyped to reject non-KernelProcessStep step types (with corresponding unit tests).
• Add Dapr runtime validation for loaded step types (and step state types) and improve error behavior when type resolution fails.
• Add new unit tests covering TypeInfo.ConvertValue and DaprStepInfo.ToKernelProcessStepInfo validation/error paths.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
dotnet/src/Experimental/Process.UnitTests/Core/ProcessBuilderTests.cs	Adds unit tests verifying AddStepFromType(Type) rejects invalid types and accepts valid step types.
dotnet/src/Experimental/Process.Runtime.Dapr/Serialization/TypeInfo.cs	Throws a KernelException when Type.GetType(...) fails, instead of deserializing with a null type.
dotnet/src/Experimental/Process.Runtime.Dapr/DaprStepInfo.cs	Validates that resolved inner step types are assignable to KernelProcessStep.
dotnet/src/Experimental/Process.Runtime.Dapr/Actors/StepActor.cs	Validates loaded inner step types and validates persisted step-state types during activation.
dotnet/src/Experimental/Process.Runtime.Dapr.UnitTests/TypeInfoTests.cs	New tests for TypeInfo.ConvertValue success + failure cases.
dotnet/src/Experimental/Process.Runtime.Dapr.UnitTests/DaprStepInfoTests.cs	New tests for DaprStepInfo.ToKernelProcessStepInfo type validation.
dotnet/src/Experimental/Process.Core/ProcessStepBuilder.cs	Adds validation in ProcessStepBuilderTyped constructor to enforce KernelProcessStep step types.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Automated Code Review

Reviewers: 4 | Confidence: 88%

✓ Correctness

This PR adds type validation checks across the Dapr process runtime to ensure that deserialized types are valid KernelProcessStep or KernelProcessStepState subclasses before use. It also fixes a potential NullReferenceException in TypeInfo.ConvertValue where Type.GetType could return null and was used with a null-forgiving operator. All changes are correct, well-tested, and improve error handling by providing clear error messages instead of obscure runtime failures.

✓ Security Reliability

This PR adds type-validation checks at several deserialization/type-resolution trust boundaries in the Dapr process runtime, hardening against arbitrary type instantiation and null reference errors. The changes are well-targeted security improvements. One minor gap: the new state-type validation in StepActor only checks non-null resolved types, leaving the pre-existing null stateType → ArgumentNullException path unimproved despite being in the same code block.

✓ Test Coverage

This PR adds type validation guards (ensuring types are KernelProcessStep/KernelProcessStepState subclasses) across ProcessStepBuilder, DaprStepInfo, StepActor, and TypeInfo, and fixes a potential NullReferenceException in TypeInfo.ConvertValue. New unit tests cover ProcessStepBuilder, DaprStepInfo, and TypeInfo changes well. However, the two new validation paths added in StepActor.cs (lines 105-108 and 381-384) have no corresponding unit tests. StepActor inherits from Dapr's Actor base class which makes direct unit testing harder, but this is a notable coverage gap for the new defensive checks.

✓ Design Approach

The PR adds IsAssignableFrom(KernelProcessStep) guards at three independent call sites (ProcessStepBuilderTyped, DaprStepInfo.ToKernelProcessStepInfo, StepActor.InitializeStep) and fixes a null-forgiving operator bug in TypeInfo.ConvertValue. The TypeInfo.cs fix is correct and straightforward. The main design concern is that the IsAssignableFrom validation is scattered across calers rather than placed at the single authoritative contract — the KernelProcessStepInfo constructor, which already checks Verify.NotNull(innerStepType) but does not validate the type hierarchy. Placing the guard there once would prevent future callers from bypassing it and eliminate duplication. The PR does improve the status quo (no guards → guards in several places), so this is not a blocking issue, but it extends an ad-hoc pattern rather than fixing it at the root.

Suggestions

• In StepActor.ActivateStepAsync, when Type.GetType(stepStateType.Value) returns null (e.g., assembly/type renamed), the new stateType is not null guard is skipped and execution falls through to JsonSerializer.Deserialize(stateObjectJson, stateType!), producing an unhelpful ArgumentNullException. Consider also throwing a descriptive KernelException for the null case, consistent with the pattern used in TypeInfo.ConvertValue and the _innerStepType check in InitializeStep.

---

Automated review by westey-m's agents