MR: pending <!-- The first line of this issue description must be one of the following: 1. `MR: Pending` 2. `MR: <MR link with trailing +>`, 3. If there are multiple MRs: ``` MRs: - <MR 1 link with trailing +>` - <MR 2 link with trailing +>` - ... ``` 4. `MR: No MR` ...and the first description line of the MR should be `Issue: <Issue link with trailing +>` For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#relationship-of-issues-to-mrs --> <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> ## Description There are two points raised during the agent MR review. And we would like to work on as an improvement in code quality. - Instead of the current approach, I recommend to define the response, etc as a proto and use the validator to ensure things are within expected bounds to avoid any surprises. See how [gitlab/api package does that](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/internal/gitlab/api/api.proto). This can be done in a follow up if you decide to go down this path. https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/merge_requests/1495#note_1924069413 - ry to avoid mutable fields where possible. They make it easier to introduce a bug. https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/merge_requests/1495#note_1926240459 ## Acceptance Criteria - [ ] address both comments ## Technical Requirements N/A ## Design Requirements None, no UI impact. ## Impact Assessment * Instance admins may want to override these values to either provide faster update and reconciliation for workspaces, or to reduce load on the monolith. * Developers may want to override these values so they can have faster feedback when developing features, e.g. have a much faster full reconciliation interval than an hour. Otherwise they have to hack the hardcoded intervals, or restart their agent to force a full reconcile. <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->