theonedev/onedev · error · TooGeneralQueryException

Regex query is too general: ${regex}

Error message

Regex query is too general: ${regex}

What it means

RegexLiterals.asNGramQuery converts a regex into Lucene n-gram queries built from literal substrings extracted from the pattern. If the regex contains no extractable literal content (pure alternations of wildcards/anchors, producing zero OR-clauses), TooGeneralQueryException is thrown because nothing can be indexed efficiently.

Source

Thrown at server-core/src/main/java/io/onedev/server/search/code/query/regex/RegexLiterals.java:70

	 * @throws TooGeneralQueryException
	 */
	public Query asNGramQuery(String fieldName, int gramSize) throws TooGeneralQueryException {
		BooleanQuery.Builder orQueryBuilder = new BooleanQuery.Builder();
		for (List<LeafLiterals> row: rows) {
			BooleanQuery.Builder andQueryBuilder = new BooleanQuery.Builder();
			for (LeafLiterals literals: row) {
				if (literals.getLiteral() != null && literals.getLiteral().length()>=NGRAM_SIZE)
					andQueryBuilder.add(new NGramLuceneQuery(fieldName, literals.getLiteral(), gramSize), Occur.MUST);
			}
			BooleanQuery andQuery = andQueryBuilder.build();
			if (andQuery.clauses().size() != 0)
				orQueryBuilder.add(andQuery, Occur.SHOULD);
		}
		BooleanQuery orQuery = orQueryBuilder.build();
		if (orQuery.clauses().size() != 0)
			return orQuery;
		else
			throw new TooGeneralQueryException("Regex query is too general: " + regex);
	}

	@Override
	public String toString() {
		StringBuilder orBuilder = new StringBuilder();
		for (List<LeafLiterals> row: rows) {
			StringBuilder andBuilder = new StringBuilder(); 
			for (LeafLiterals literals: row) {
				if (!Strings.isNullOrEmpty(literals.getLiteral())) {
					if (andBuilder.length() != 0)
						andBuilder.append("&");
					andBuilder.append(literals.getLiteral());
				}
			}
			if (orBuilder.length() != 0)
				orBuilder.append("|");
			orBuilder.append(andBuilder);
		}

View on GitHub (pinned to d44925c47c)

Solutions

  1. Include literal characters in the regex (e.g. 'foo.*bar' instead of '.*'), since literals are extracted into n-gram terms.
  2. Anchor the pattern with concrete text; drop redundant '.*' prefixes/suffixes — they are implicit.
  3. Catch TooGeneralQueryException at the search entry and ask the user for a more specific pattern.

Example fix

// before
new RegexLiterals(".*").asNGramQuery(BLOB_TEXT.name(), NGRAM_SIZE);
// after
new RegexLiterals("foo.*bar").asNGramQuery(BLOB_TEXT.name(), NGRAM_SIZE);
Defensive patterns

Strategy: validation

Validate before calling

if (regex != null && regex.replaceAll("[\\W_]|\\\\[dDwWsS]", "").isEmpty())
    throw new IllegalArgumentException("Regex has no literal content for n-gram indexing");

Type guard

boolean hasRegexLiterals(String pattern) {
    return pattern != null && pattern.replaceAll("[^A-Za-z0-9]", "").length() > 0;
}

Try / catch

try {
    q = new RegexLiterals(pattern).asNGramQuery(field, ngramSize);
} catch (TooGeneralQueryException e) {
    return Result.error("Regex too general: " + pattern);
}

Prevention

When it happens

Trigger: Calling asNGramQuery on a RegexLiterals built from a pattern with no literal characters, e.g. '.*', '[a-z]*', '(a|b)*' — the derived BooleanQuery has no clauses so the exception is thrown.

Common situations: User submits a purely wildcard regex like '.*' into regex-based code search; a programmatic TextQuery with regex=true built from an unanchored dot-star pattern.

Related errors


AI-assisted analysis of theonedev/onedev@d44925c47c (2026-09-06). Data as JSON: /api/errors/838b93f3151b0e40. Report an issue: GitHub.