AlistGo/alist · warning
per_page can't < 1
Error message
per_page can't < 1
What it means
Returned by SearchReq.Validate when PerPage is less than 1. The search backend needs a positive page size; per_page=0 or negative would produce empty or invalid limit/offset SQL. Surfaces as a 400 from the search handler.
Source
Thrown at internal/model/search.go:35
Keywords string `json:"keywords"`
// 0 for all, 1 for dir, 2 for file
Scope int `json:"scope"`
PageReq
}
type SearchNode struct {
Parent string `json:"parent" gorm:"index"`
Name string `json:"name"`
IsDir bool `json:"is_dir"`
Size int64 `json:"size"`
}
func (p *SearchReq) Validate() error {
if p.Page < 1 {
return fmt.Errorf("page can't < 1")
}
if p.PerPage < 1 {
return fmt.Errorf("per_page can't < 1")
}
return nil
}
func (s *SearchNode) Type() string {
return "SearchNode"
}
View on GitHub (pinned to 843d9dc814)
Solutions
- Send per_page >= 1 (e.g. a sane default like 30).
- Validate/clamp the page-size input in the client before sending.
- If 'all results' is needed, implement explicit export logic rather than per_page=0.
Defensive patterns
Strategy: validation
Validate before calling
if req.PerPage < 1 { req.PerPage = 30 } // sane default
if err := req.Validate(); err != nil { /* 400 */ } Try / catch
if err := searchReq.Validate(); err != nil {
c.JSON(http.StatusBadRequest, gin.H{"message": err.Error()})
return
} Prevention
- Always send an explicit per_page >= 1.
- Clamp page-size selectors to a minimum of 1 (and a sane maximum) in the UI.
- Do not use per_page=0 to mean 'unlimited' — it is rejected.
When it happens
Trigger: Calling search with per_page=0, negative, or omitting it when the binding default is zero.
Common situations: UI page-size selector allowing 0 or blank; client passing an unset config value; stress scripts sending per_page=0 hoping for 'all results'.
Related errors
AI-assisted analysis of AlistGo/alist@843d9dc814 (2026-08-15).
Data as JSON: /api/errors/ef0cf74e3f4c2392.
Report an issue: GitHub.