docs/docs/features/request-validation.md (3)

147-160: Enhance the defaults documentation with a comparison table

The explanation of default values and pointer usage is good, but could be even clearer with a comparison table showing different scenarios. Consider adding a table like this after line 160:

| Client Input | Field Type | Default Value | Result | Explanation |
|--------------|------------|---------------|---------|-------------|
| (not sent)   | bool       | true          | true    | Zero value (false) overridden by default |
| false        | bool       | true          | true    | Explicit false overridden by default |
| (not sent)   | *bool      | true          | true    | Nil pointer gets default value |
| false        | *bool      | true          | false   | Explicit false preserved |

This would help readers better understand the behavior differences between pointer and non-pointer fields.

🧰 Tools

🪛 LanguageTool

[grammar] ~147-~147: Probable usage error. Use “and” after ‘both’.
Context: ...xistence of a server-side default value as well as to automatically have Huma set that val...

(BOTH_AS_WELL_AS)

🪛 Markdownlint

153-153: Column: 1
Hard tabs

(MD010, no-hard-tabs)

---

154-154: Column: 1
Hard tabs

(MD010, no-hard-tabs)

---

155-155: Column: 1
Hard tabs

(MD010, no-hard-tabs)

---

147-147: Fix grammar in the defaults description

The phrase "both ... as well as" is redundant. Consider revising to:

-The `default` field validation tag listed above is used to both document the existence of a server-side default value as well as to automatically have Huma set that value for you.
+The `default` field validation tag listed above documents the existence of a server-side default value and automatically has Huma set that value for you.

🧰 Tools

🪛 LanguageTool

[grammar] ~147-~147: Probable usage error. Use “and” after ‘both’.
Context: ...xistence of a server-side default value as well as to automatically have Huma set that val...

(BOTH_AS_WELL_AS)

---

151-157: Expand the example with more real-world scenarios

Consider enhancing the example to show more real-world use cases where default values and zero values are semantically important. For instance:

type ConfigInput struct {
    Body struct {
        // Pointer types for fields where zero values are meaningful
        Enabled    *bool    `json:"enabled" default:"true"`
        Threshold  *float64 `json:"threshold" default:"0.5"`
        RetryCount *int     `json:"retryCount" default:"3"`
        
        // Non-pointer types where zero values have no special meaning
        Name    string   `json:"name" default:"default-config"`
        Tags    []string `json:"tags" default:"[\"system\"]"`
    }
}

Also consider adding a "Common Pitfalls" subsection highlighting:

• When to use pointer vs non-pointer types
• How default values interact with validation rules
• Performance implications of using pointers

🧰 Tools

🪛 Markdownlint

153-153: Column: 1
Hard tabs

(MD010, no-hard-tabs)

---

154-154: Column: 1
Hard tabs

(MD010, no-hard-tabs)

---

155-155: Column: 1
Hard tabs

(MD010, no-hard-tabs)

huma.go (8)

215-216: Add test coverage for the new panic condition

The panic introduced for pointers to structs with default values (panic("pointers to structs cannot have default values")) is not covered by tests. Consider adding a test case to ensure this scenario is properly handled and to improve test coverage.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 216-216: huma.go#L216
Added line #L216 was not covered by tests

---

263-266: Add test coverage for handling invalid reflect values in every function

The added check for invalid reflect.Value after reflect.Indirect(current) ensures that optional fields that may be nil are properly handled. However, this logic is not covered by tests. Adding test cases that cover this scenario would improve test coverage and ensure robustness.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 265-266: huma.go#L265-L266
Added lines #L265 - L266 were not covered by tests

---

279-279: Add test coverage for map iteration in every function

The line handling map iteration (r.every(current.MapIndex(k), path, v, f)) is not covered by tests. Consider adding test cases where the every function operates on maps to ensure this functionality is correctly validated.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 279-279: huma.go#L279
Added line #L279 was not covered by tests

---

313-314: Add test coverage for invalid reflect values in everyPB function

The check for invalid reflect.Value after reflect.Indirect(current) in the everyPB method handles cases where optional fields may be omitted. This logic is not covered by tests. Consider adding test cases to validate this scenario.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 313-314: huma.go#L313-L314
Added lines #L313 - L314 were not covered by tests

---

867-868: Add test coverage for handling invalid reflect values when processing input parameters

The check for invalid reflect.Value after reflect.Indirect(f) ensures that optional parameters are properly handled when they are omitted. This case is not covered by tests. Consider adding test cases to improve test coverage and ensure the input parameter parsing is robust.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 867-868: huma.go#L867-L868
Added lines #L867 - L868 were not covered by tests

---

1319-1322: Add test coverage for setting default values on pointer fields

The logic for initializing pointers and setting default values when item.IsZero() is true ensures that default values are correctly applied to pointer fields. Consider adding test cases to cover various pointer types and verify that defaults are set appropriately.

---

1348-1351: Add test coverage for handling invalid reflect values in resolver processing

The check for invalid reflect.Value after reflect.Indirect(item) when processing resolvers ensures that optional fields are properly handled when they are nil or omitted. Consider adding tests to cover this scenario and improve robustness.

---

1434-1437: Add test coverage for handling invalid reflect values in output header serialization

The check for invalid reflect.Value after reflect.Indirect(f) when serializing output headers ensures that optional header fields are correctly handled when they are nil or omitted. This logic is not covered by tests. Consider adding test cases to cover this scenario.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 1436-1437: huma.go#L1436-L1437
Added lines #L1436 - L1437 were not covered by tests

huma_test.go (1)

38-38: Use proper logging instead of fmt.Println for recovered panics

Using fmt.Println(rvr) in the Recoverer middleware writes directly to the standard output, which may not be appropriate for production environments. Consider using a logging framework to log the recovered panic value, which allows for better control over log levels and destinations.

You can modify the code as follows:

-	fmt.Println(rvr)
+	log.Printf("Recovered panic: %v", rvr)

Ensure that the log package is properly configured, or use the project's preferred logging system.

Configuration used: CodeRabbit UI
Review profile: CHILL

-	assert.Panics(t, func() {
+	err := func() error {
		huma.Register(app, huma.Operation{
			OperationID: "bug",
			Method:      http.MethodGet,
			Path:        "/bug",
		}, func(ctx context.Context, input *struct {
			Body struct {
				Value *struct {
					Field string `json:"field"`
				} `json:"value,omitempty" default:"{}"`
			}
		}) (*struct{}, error) {
			return nil, nil
		})
-	})
+		return nil
+	}()
+	assert.Error(t, err, "Expected an error when setting a default for a pointer to struct")