What causes "regexps are not allowed on IRIs" in cayleygraph/cayley?

Match on a literal property instead: save the relevant string field and regex against it.

errRegexpOnIRI

errRegexpOnIRI

Error message

regexps are not allowed on IRIs

What it means

errRegexpOnIRI is thrown by cmpRegexp when a regular-expression filter is applied to a quad.IRI or quad.BNode value while refs are disallowed. The engine intentionally disallows regex matching against node identifiers to avoid expensive/unbounded scans, permitting regexps only on literal strings (unless allowRefs is enabled).

Source

Thrown at query/gizmo/errors.go:21

// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

package gizmo

import "fmt"

var (
	errNoVia       = fmt.Errorf("expected predicate list")
	errRegexpOnIRI = fmt.Errorf("regexps are not allowed on IRIs")
)

type errArgCount2 struct {
	Expected int
	Got      int
}

func (e errArgCount2) Error() string {
	return fmt.Sprintf("expected %d argument, got %d", e.Expected, e.Got)
}

type errArgCount struct {
	Got int
}

func (e errArgCount) Error() string {
	return fmt.Sprintf("unexpected arguments count: %d", e.Got)
}

View on GitHub (pinned to 81dcd7d73e)

Solutions

Match on a literal property instead: save the relevant string field and regex against it.
Match the exact IRI with .Is("<...>") rather than a regexp.
If IRI regex is truly needed, run in a context/configuration where allowRefs is enabled.

Example fix

// before
mori.g.V().filter(regex("person"))
// after
mori.g.V().has("<name>", regex("person"))

Defensive patterns

Strategy: validation

Validate before calling

if (isIRI(value) && usesRegex(filter)) { console.warn('regex on IRI is not allowed; use has() on a literal property'); }

Type guard

function isIRI(v) { return typeof v === 'string' && v.startsWith('<') && v.endsWith('>'); }

Try / catch

try { g.V().filter(regex('person')); } catch (e) { if (String(e).includes('regexps are not allowed on IRIs')) { /* switch to has() on a literal */ } throw e; }

Prevention

Apply regex only to literal properties via has()/save()
Use Is('<exact-iri>') for identifier matching
Avoid enabling allowRefs unless you accept the scan cost

When it happens

Trigger: Using a regexp-based filter (e.g. .filter(regex(...)) or comparison paths that reach environ.go:210/:214) where the current value is an IRI or blank node identifier rather than a string literal, and allowRefs is false.

Common situations: Scripts attempting regex on node IDs like g.V().out().filter(regex("person")) where 'person' matches IRIs; users often expect regex to work on IRIs as in other graph query languages.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

AI-assisted analysis of cayleygraph/cayley@81dcd7d73e (2026-09-06). Data as JSON: /api/errors/88129c9f4c7b941b. Report an issue: GitHub.