This is unnecessary. max_attempts has a default value. The purpose of a default value is to supply a value if none is provided. If max_attempts is required, then the user must provide a value, meaning there's no point in having a default.

No, not having this means the user can submit this in the UI:

The ZerologonOptions pydantic object will populate it with 2000 because of the default value that it has, but the user doesn't know that. The behavior is ambiguous.

This change disables submission:

That's a UI issue, not an issue with the schema. Don't let UI requirements leak down into other components.

It seems that the UI should populate the field with the default value, not that the schema should have knowledge of the UI's requirements.

IIRC, the only reason we have the schema files in the plugins is to show the configurations in the UI (for rjsf).

The schema files define what configuration the plugin accepts. This allows any user of the API to examine how the agent can be configured. It also allows both the agent and the island to verify/validate a supplied configuration.

I don't think that's how we thought of it initially. Hadoop and SMB have the "required" field in their config schema files.

It's fine if we're changing it now but before we do that, we should think about how we'll make the changes in the UI. I don't see a clean way to do it as of now, but more importantly, changing a plugin's config schema would most likely require changes to the frontend, defeating the whole purpose of implementing a plugin system.

I don't think that's how we thought of it initially.

It is. I know because that's how I designed it.

Hadoop and SMB have the "required" field in their config schema files.

We should remove it from those plugins as well.

It's fine if we're changing it now but before we do that, we should think about how we'll make the changes in the UI.

I've created issue #3297 to cover this. We'll fix it next week.

changing a plugin's config schema would most likely require changes to the frontend, defeating the whole purpose of implementing a plugin system.

How do you figure? The plugin specifies a schema, the frontend parses and displays that schema. The whole point is that changes to the schema shouldn't require frontend changes. If we change fields from required to optional and that forces a UI change (like it does now), this is evidence of a deficiency in the frontend.

How does the UI know which fields to mark as "required" if the config schema doesn't have that information?

The config schema can contain required fields. But if it does, those fields shouldn't have default values. If fields have default values, then they are, by definition, not required.

Dropped the commit

Good catch