Templates: error on missing required value

[andig]

Fix #25930

TODO

• for tests instantiate templates in test mode to avoid required field errors
• verify ui tests

[sourcery-ai]

Hey there - I've reviewed your changes - here's some feedback:

• The required-field check currently only runs when val != nil, so a required parameter that is completely missing or explicitly set to nil will not trigger an error; consider treating nil as missing for required params as well.
• Using reflect.ValueOf(val).IsZero() on every render may be heavier than necessary; if the values are expected to be simple types (e.g., strings, numbers), you could replace reflection with type-specific zero checks to keep this hot path lighter.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The required-field check currently only runs when `val != nil`, so a required parameter that is completely missing or explicitly set to `nil` will not trigger an error; consider treating `nil` as missing for required params as well.
- Using `reflect.ValueOf(val).IsZero()` on every render may be heavier than necessary; if the values are expected to be simple types (e.g., strings, numbers), you could replace reflection with type-specific zero checks to keep this hot path lighter.

## Individual Comments

### Comment 1
<location> `util/templates/template_test.go:48-50` </location>
<code_context>
+		},
+	}
+
+	_, _, err := tmpl.RenderResult(0, map[string]any{
+		"Param": "foo",
+	})
+	require.NoError(t, err)
+
</code_context>

<issue_to_address>
**suggestion (testing):** Assert on the error message content for the failing required case

Since the implementation returns a specific error message (e.g., `missing required \`param\``) when required validation fails, the test should assert on that message using `require.ErrorContains` or `require.EqualError`, not just that an error occurred. This will better guard against regressions where required-field validation changes or is removed.

Suggested implementation:

```golang
func TestRequired(t *testing.T) {
	tmpl := &Template{
		TemplateDefinition: TemplateDefinition{
			Params: []Param{
				{
					Name:     "param",
					Required: true,
				},
			},
		},
	}

	_, _, err := tmpl.RenderResult(0, map[string]any{})
	require.ErrorContains(t, err, "missing required `param`")

	_, _, err = tmpl.RenderResult(0, map[string]any{
		"Param": "foo",
	})
	require.NoError(t, err)
}

```

If the actual error string produced by the implementation differs (e.g., different wording or punctuation), update `"missing required \`param\`"` in the test to exactly match the real error text or a stable substring of it. Also, if the initial failing call currently uses a different argument (e.g., `nil` instead of `map[string]any{}`), apply the `require.ErrorContains` assertion at that call site without changing the arguments unless necessary.
</issue_to_address>

### Comment 2
<location> `util/templates/template_test.go:37-45` </location>
<code_context>
 }
+
+func TestRequired(t *testing.T) {
+	tmpl := &Template{
+		TemplateDefinition: TemplateDefinition{
+			Params: []Param{
+				{
+					Name:     "param",
+					Required: true,
+				},
+			},
+		},
+	}
+
</code_context>

<issue_to_address>
**question (testing):** Clarify or test the key casing behavior between `Param` and `param`

The template param is named `"param"`, but the test passes `"Param"` in the map. If case-insensitive matching is intended, please make that explicit (e.g., a dedicated `TestRequired_CaseInsensitiveKey` or a short comment). If not, align the `Name` and map key to avoid the test accidentally depending on unspecified behavior.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[andig]

@naltatis with this change UI tests are failing due to missing required fields. The errors are real and probably due to faulty test cases. Could you take a look if it would be feasible to fix the tests?