I find "required" a nice JSON schema feature we should try to support in the most predictable way. Even if we decided we cannot ensure required properties at the top level because of the technical problems exposed, we probably would want to support them at deeper levels (one level of support so far).

Looking closer how to deal with the top-level issue, schema validity is checked in the following scenarios:

1. In the onJsonValidateSave hook when directly using the config page editor interface
2. In the ApiEdit when handling updates (eg. from the editor client)
3. In the DataProvider when requesting to load a valid configuration, used by WikiPageConfigProvider

For all cases top level keys being present is relevant if there's no default value we can use. But particularly for cases (1) and (2) I find it more relevant since a missing property leads to removing it or overwriting it with a default which results in some kind of information loss. In case (3) missing required properties could lead to an invalid config (maybe recoverable if merged with defaults) and that can cause some application errors but not as bad as for prior cases.

If we agree in these observations, an approach we could take is to allow required properties at the top-level but only use them for cases (1) and (2). For (3) we could check which top level config options we were able to retrieve and subtract the missing ones from the required top-level ones. @Urbanecm_WMF what do you think? I'm happy to make the changes to support "required" if this sounds reasonable.

Hello @Sgs, thanks for taking a look at this. Generally speaking, I agree with your observations. If we only check required on save (and not in the before-reading check in DataProvider), I have no concerns about it being introduced.

This approach is similar to the concept of validation warnings (blocking saving, but not reading) and validation errors (blocking everything), which we introduced in GrowthExperiments. Back then, it was done as part of T312576: Structured mentor list should validate the maximum length of a mentor message (see patch for additional context). This makes me wonder: How should we implement the validation warning system in CommunityConfiguration, now that we have fully-blown JSON Schemas? Should we have a generic concept to mark certain validation rules as "soft" (ignorable on reads, but enforced on writes)? If so, is there a reasonable JSONSchema extension we could use/create to record this sort of decisions within the schema itself? How can we make ReflectionSchemaSource read declarations that are CommunityConfiguration-specific? Is that even a good idea?

Considering the required question is now resolved, we can probably close this task as resolved (and fill another one for implementing the changes themselves). I'm not doing that right now, as I see you moved it back to Doing and to give the opportunity to discuss the questions I raised above.