Troubleshooting

A regex rule is rejected for nested quantifiers or alternation on a pattern that looks safe

Symptom: Creating a regex source-link rule fails with a 422 naming "nested quantifiers" or "an alternation... under a quantifier" — even on a pattern that looks harmless, e.g. (foo|bar)+.

Cause: The guard rejects any quantified group whose body contains another quantifier or a |, without analyzing whether that specific pattern is actually capable of catastrophic backtracking. It's a shape check meant to close off both attack families cheaply, not a runtime analysis of the pattern — a few false positives are the accepted cost of never letting a pathological one through.

Check: _guard_regex_value in backend/app/api/admin/common/schemas_links.py:104-140. There is no override or exception path — simplify the pattern (drop the alternation or nesting) or switch to exact_name / name_prefix for that link. See Create a rule for the full set of caps.

A team member with a source scope sees other people's rows in the unassigned-links queue

Symptom: A teammate whose access is limited to specific source domains still sees unassigned links that belong to sources outside their scope.

Cause: list_unassigned_links doesn't apply team_source_scope the way list_source_links does. A queued row has no domain_source yet — that's the entire premise of the queue — so there's nothing on the row itself to filter against.

Check: compare list_source_links (filters by team_source_scope) against list_unassigned_links (doesn't) in backend/app/products/club/api/admin/source_links.py:82-94 vs. :211-223. This is a known gap in the current code, not something to work around client-side — until it's closed, treat the unassigned-links queue as visible to any admin regardless of a member's source scope.

What's next

Back to Traffic sources for the full task list.