What causes "must be greater than zero" in router-for-me/CLIProxyAPI?

Send a positive integer, e.g. ?limit=100

must be greater than zero

Error message

must be greater than zero

What it means

Returned by parseLimit (logs.go:1227) when the `limit` query parameter parses as an integer but is zero or negative. The limit bounds the number of lines returned; only positive values are meaningful, so limit=0 or limit=-5 is rejected with this distinct message (note: an absent parameter is fine — only an explicitly non-positive value fails).

Source

Thrown at internal/api/handlers/management/logs.go:1227

	}
	ts, err := strconv.ParseInt(value, 10, 64)
	if err != nil || ts <= 0 {
		return 0
	}
	return ts
}

func parseLimit(raw string) (int, error) {
	value := strings.TrimSpace(raw)
	if value == "" {
		return 0, nil
	}
	limit, err := strconv.Atoi(value)
	if err != nil {
		return 0, fmt.Errorf("must be a positive integer")
	}
	if limit <= 0 {
		return 0, fmt.Errorf("must be greater than zero")
	}
	return limit, nil
}

func parseTimestamp(line string) int64 {
	if strings.HasPrefix(line, "[") {
		line = line[1:]
	}
	if len(line) < 19 {
		return 0
	}
	candidate := line[:19]
	t, err := time.ParseInLocation("2006-01-02 15:04:05", candidate, time.Local)
	if err != nil {
		return 0
	}
	return t.Unix()
}

View on GitHub (pinned to 78f0c4079e)

Solutions

Send a positive integer, e.g. ?limit=100
If you mean 'no limit', omit the parameter instead of sending 0
Guard client-side: if limit <= 0 do not include it in the query string

Example fix

// before
limit := total - fetched // may be 0
curl-ish: /management/logs?limit=" + strconv.Itoa(limit)

// after
q := url.Values{}
if limit > 0 {
	q.Set("limit", strconv.Itoa(limit))
}

Defensive patterns

Strategy: validation

Validate before calling

q := url.Values{}
if limit > 0 {
	q.Set("limit", strconv.Itoa(limit))
}
// never send limit=0 or negative values

Type guard

function isPositiveInt(raw string) bool {
	return /^\d+$/.test(raw) && parseInt(raw, 10) > 0;
}

Prevention

Treat 0 as 'omit the parameter', never send it explicitly
Clamp pagination math results to a minimum of 1 or drop the parameter
Unit-test client query builders for boundary values 0 and -1

When it happens

Trigger: GET /management/logs?limit=0, ?limit=-1, or a client computing limit as count-pageSize that underflowed to 0.

Common situations: Pagination math bugs (page size larger than total producing 0); clients treating 0 as 'unlimited' — the API wants the parameter omitted instead.

Related errors

AI-assisted analysis of router-for-me/CLIProxyAPI@78f0c4079e (2026-08-15). Data as JSON: /api/errors/a9e3fc6eb9d5ea5b. Report an issue: GitHub.