Severity: Warning

Summary

A typo in the method name ShouldSerializEnableSizeRotation (missing an e — should be ShouldSerializeEnableSizeRotation) causes Newtonsoft.Json to never invoke it, so EnableSizeRotation is serialized unconditionally instead of only when it has a value.

File and line

src/Servy.Core/DTOs/ServiceDto.cs:430:

public bool ShouldSerializEnableSizeRotation() => EnableSizeRotation.HasValue;
//              ^--- missing 'e'; should be ShouldSerializeEnableSizeRotation

For comparison, every sibling in the same block (lines 421–474) spells the convention correctly:

public bool ShouldSerializeStartupType()       => StartupType.HasValue;
public bool ShouldSerializePriority()          => Priority.HasValue;
public bool ShouldSerializeRotationSize()      => RotationSize.HasValue;   // <- immediate neighbour, correct
public bool ShouldSerializeEnableDateRotation()=> EnableDateRotation.HasValue;
...

Explanation

Newtonsoft.Json's conditional-serialization convention discovers methods by exact name pattern ShouldSerialize<PropertyName>(). A typo means the method is invisible to the serializer. The effect:

• Intended: EnableSizeRotation is omitted from exported JSON/XML when null.
• Actual: EnableSizeRotation is always emitted — even as null — which is asymmetric with every other optional field on this DTO.

Concrete consequences:

1. Exported service config files contain stray "EnableSizeRotation": null entries that were supposed to be absent, diverging from the rest of the DTO's serialization shape.
2. Round-trip equality tests between "default" DTOs and exported/imported DTOs may fail or silently add noise.
3. If any downstream consumer (manifest diff, config-sync tool) treats presence vs absence of a key as meaningful, this field reports "explicitly set" when it wasn't.

Suggested fix

Single-character rename:

public bool ShouldSerializeEnableSizeRotation() => EnableSizeRotation.HasValue;

No other call sites need updating — the serializer discovers these methods by name reflection.