What causes "invalid regular expression" in iawia002/lux?

When editing the pattern, test it in isolation with regexp.MustCompile first.

ErrInvalidRegularExpression

ErrInvalidRegularExpression

Error message

invalid regular expression

What it means

Sentinel returned when a runtime regexp.Compile inside an extractor fails. The only throw site in the tree is pornhub.go:83, where the constant script-tag pattern fails to compile. Because the pattern is hardcoded and valid, this is essentially a maintenance-time defect: it only fires if someone edits the pattern into an invalid expression, and the sentinel then hides the real compile message.

Source

Thrown at extractors/errors.go:10

package extractors

import (
	"errors"
)

var (
	// ErrURLParseFailed defines url parse failed error.
	ErrURLParseFailed            = errors.New("url parse failed")
	ErrInvalidRegularExpression  = errors.New("invalid regular expression")
	ErrURLQueryParamsParseFailed = errors.New("url query params parse failed")
	ErrBodyParseFailed           = errors.New("body parse failed")
)

View on GitHub (pinned to dd00f6d258)

Solutions

When editing the pattern, test it in isolation with regexp.MustCompile first.
Return the underlying compile error instead of the sentinel so the real problem surfaces.
Move the pattern to a package-level regexp.MustCompile so a bad regex fails at build/test time, not at runtime.

Example fix

// before
reg, err := regexp.Compile(`<script\b[^>]*>([\s\S]*?)</script>`)
if err != nil {
	return nil, errors.WithStack(extractors.ErrInvalidRegularExpression)
}
// after — compile once at package scope; bad patterns fail at build/test time
var scriptRe = regexp.MustCompile(`<script\b[^>]*>([\s\S]*?)</script>`)

Defensive patterns

Strategy: try-catch

Type guard

func isInvalidRegularExpression(err error) bool {
	return errors.Is(err, extractors.ErrInvalidRegularExpression)
}

Try / catch

If caught, treat it as a code defect, not a runtime condition: report it upstream with the extractor name; there is no input-level remedy.

Prevention

Prefer package-level regexp.MustCompile so bad patterns fail at build time
Return the underlying compile error instead of the sentinel in library code
Add unit tests covering every regex an extractor relies on

When it happens

Trigger: A contributor edits the pornhub script regex into a malformed expression (unbalanced parens, bad escapes); no user input reaches this path.

Common situations: Hand-edits to extractor regexes without running tests; refactors that touch the pattern string.

Related errors

AI-assisted analysis of iawia002/lux@dd00f6d258 (2026-08-15). Data as JSON: /api/errors/21781c82566d5249. Report an issue: GitHub.