Subnet Management - General Discussion

[quint]

@Lorimer

@Manu, @dsharifi, @andrea, would it be feasible to only specify the payload fields that are necessary in future proposals, or is there a reason for the NULL fields that I’m not considering?

One thing that occurred to me while going through these proposals is that the way subnet config update payloads are constructed is very noisy (meaning there’s a slight danger that there could be a sneaky config change that’s harder to spot, particularly if there are 10 or so other proposals that are submitted at the same time, and only one of them has a subtle deviation).

Given that almost all of the subnet config fields are optional, can I ask why every field is always explicitly included in the payload (with a NULL value). Why not just omit the optional fields that are not being set by the proposal. This would make it very easy to spot exactly what’s changing from a mile off, instead of having to very carefully scan the payload and risk missing something.

I completely agree with Lorimer’s suggestion. Omitting the optional fields that are not being set would streamline the payloads and make it much easier to spot the actual changes. Reducing noise in the config update proposals would help minimize the risk of overlooking subtle deviations, especially when multiple proposals are submitted at once. It seems like a practical improvement with no downsides, as long as there aren’t any hidden dependencies on NULL values that we might be missing.