Tencent/APIJSON · error · IllegalArgumentException

{}/page:value 中 value 的值不合法!必须在 {}-{} 内 !

Error message

{}/page:value 中 value 的值不合法!必须在 {}-{} 内 !

What it means

The page number in []:{} is normalized (page or 0, minus getMinQueryPage(), commonly 0- or 1-based compat) and must fall in [0..getMaxQueryPage()]. Outside that range IllegalArgumentException is thrown with the exact min-max bounds in the message.

Source

Thrown at APIJSONORM/src/main/java/apijson/orm/AbstractParser.java:1372

			case "1":
			case apijson.JSONRequest.QUERY_TOTAL_STRING:
				query2 = apijson.JSONRequest.QUERY_TOTAL;
				break;
			case "2":
			case apijson.JSONRequest.QUERY_ALL_STRING:
				query2 = apijson.JSONRequest.QUERY_ALL;
				break;
			default:
				throw new IllegalArgumentException(path + "/" + apijson.JSONRequest.KEY_QUERY + ":value 中 value 的值不合法!必须在 [0, 1, 2] 或 [TABLE, TOTAL, ALL] 内 !");
			}
		}

		int minPage = getMinQueryPage(); // 兼容各种传 0 或 null/undefined 自动转 0 导致的问题
		int page2 = page == null || page == 0 ? 0 : page - minPage;

		int maxPage = getMaxQueryPage();
		if (page2 < 0 || page2 > maxPage) {
			throw new IllegalArgumentException(path + "/" + apijson.JSONRequest.KEY_PAGE + ":value 中 value 的值不合法!必须在 " + minPage + "-" + maxPage + " 内 !");
		}

		//不用total限制数量了,只用中断机制,total只在query = 1,2的时候才获取
		int count2 = isSubquery || count != null ? (count == null ? 0 : count) : getDefaultQueryCount();
		int max = isSubquery ? count2 : getMaxQueryCount();

		if (count2 < 0 || count2 > max) {
			throw new IllegalArgumentException(path + "/" + apijson.JSONRequest.KEY_COUNT + ":value 中 value 的值不合法!必须在 0-" + max + " 内 !");
		}

		request.remove(apijson.JSONRequest.KEY_QUERY);
		request.remove(apijson.JSONRequest.KEY_COMPAT);
		request.remove(apijson.JSONRequest.KEY_COUNT);
		request.remove(apijson.JSONRequest.KEY_PAGE);
		request.remove(apijson.JSONRequest.KEY_JOIN);
		Log.d(TAG, "onArrayParse  query = " + query + "; count = " + count + "; page = " + page + "; join = " + join);

		if (request.isEmpty()) { // 如果条件成立,说明所有的 parentPath/name:request 中request都无效!!! 后续都不执行,没必要还原数组关键词浪费性能

View on GitHub (pinned to 5284052872)

Solutions

  1. Clamp page client-side to the range shown in the message (typically 0-100 or 1-100)
  2. When deep-paginating, use @column with ordered unique keys or @explain'd keyset pagination instead of high offsets
  3. Align the client's page base with getMinQueryPage() of the server
  4. Raise getMaxQueryPage() in your Parser subclass only if the data volume justifies it

Example fix

// before
{"[]":{"page":101,"count":10,"User":{}}}
// after
{"[]":{"page":100,"count":10,"User":{}}}
Defensive patterns

Strategy: validation

Validate before calling

int p = page == null ? 0 : page;
if (p < 0 || p > MAX_PAGE) throw new IllegalArgumentException("page out of range: " + p);

Type guard

boolean pageInRange(Integer page, int min, int max) {
  return page == null || (page >= min && page <= max);
}

Prevention

When it happens

Trigger: {"[]":{"page":100000,...}} beyond maxQueryPage (default 100), or a negative page, or page after normalization below 0 because the client assumed a different min-page base than the server uses.

Common situations: Client computes page from total/count without ceiling; infinite-scroll keeps incrementing past the cap; server tightened maxQueryPage to limit scan depth; off-by-one when minQueryPage is 1 on server but client sends 0-based 0 with negative computed index on another deploy.

Related errors


AI-assisted analysis of Tencent/APIJSON@5284052872 (2026-08-14). Data as JSON: /api/errors/feca60b55ab3a7f4. Report an issue: GitHub.