Skip to content

fix(query-language): don't treat dash before a non-prefix colon word as negation#1301

Open
devteamaegis wants to merge 1 commit into
sourcebot-dev:mainfrom
devteamaegis:fix/negate-non-prefix-colon-word
Open

fix(query-language): don't treat dash before a non-prefix colon word as negation#1301
devteamaegis wants to merge 1 commit into
sourcebot-dev:mainfrom
devteamaegis:fix/negate-non-prefix-colon-word

Conversation

@devteamaegis

@devteamaegis devteamaegis commented Jun 11, 2026 •
edited by coderabbitai Bot
Loading

Copy link
Copy Markdown

What's broken

A search query that negates a bare word containing a colon crashes the parser, and parseQuerySyntaxIntoIR (strict mode) turns that into a user-facing FAILED_TO_PARSE_QUERY 400 — the whole search fails. Examples: -foo:bar, -http://example.com, -time:12. Note foo:bar without the dash parses fine; only the negated form breaks.

"-foo:bar"            => SyntaxError: No parse at 1
"-http://example.com" => SyntaxError: No parse at 1
"-file:bar"           => OK   (real prefix negation still works)

Why it happens

The grammar only allows NegateExpr { negate (PrefixExpr | ParenExpr) }, but negateToken emitted the negate token whenever the following word contained any colon, not when it actually started with a known prefix keyword. So -foo:bar emitted negate and then left a bare word with no PrefixExpr to attach to → no parse.

Fix

Only emit negate when the dash is immediately followed by a known prefix keyword, using the existing startsWithPrefixAt helper. Bare words with colons fall through to wordToken.

Test

Added cases to negation.txt: -http://example.com, -time:12, and repo:x -foo:bar now parse as Terms; the existing -file:... prefix-negation cases still pass.

Summary by CodeRabbit

  • Bug Fixes

    • Query parsing now only treats dash-prefixed items as negation when they begin with recognized prefix keywords, avoiding incorrect negation of URLs and other colon-containing terms.

  • Tests

    • Added tests covering negation with non-prefix colon terms and mixed prefix-plus-term expressions to ensure correct parsing behavior.

@devteamaegis
fix(query-language): don't treat a dash before a non-prefix colon wor…
e353251 
…d as negation

A query like `-foo:bar` or `-http://example.com` raised a SyntaxError.
The negate tokenizer accepted `-` as negation whenever any colon appeared
in the following word, but the grammar only allows a NegateExpr to wrap a
known PrefixExpr. With no matching prefix, the strict parser used in search
failed the whole query. Now negation is only emitted when the dash is
immediately followed by a known prefix keyword; other colon-bearing words
parse as a single Term.
@coderabbitai

coderabbitai Bot commented Jun 11, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 36b5ba1f-5829-4a41-bd23-99a65405d05f

📥 Commits

Reviewing files that changed from the base of the PR and between 295e6a6 and e353251.

📒 Files selected for processing (2)
  • packages/queryLanguage/src/tokens.ts
  • packages/queryLanguage/test/negation.txt
🚧 Files skipped from review as they are similar to previous changes (2)
  • packages/queryLanguage/test/negation.txt
  • packages/queryLanguage/src/tokens.ts

Walkthrough

The PR refactors negation token recognition to rely on prefix keyword matching instead of colon-position scanning. The negateToken function now only emits the negate token when a dash precedes a known prefix keyword; otherwise, the input is passed to wordToken. Three test cases validate the new behavior for non-prefix colon-containing terms.

Changes

Negation Tokenization Refactor

Layer / File(s) Summary
Negation token logic update
packages/queryLanguage/src/tokens.ts		 negateToken now uses startsWithPrefixAt(input, offset) to determine whether a dash starts a negation, replacing the previous colon-scanning approach. Dashes followed by non-prefix text (like arbitrary -foo:bar or -http://example.com) are no longer tokenized as negate and are left for wordToken.
Negation test validation
packages/queryLanguage/test/negation.txt		 Added three test cases covering the new behavior: dashes with non-prefix URLs are parsed as single terms, dashes with unknown colon keys are parsed as single terms, and mixed expressions combining prefix terms with non-prefix negated colon terms form AndExpr correctly.

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and specifically describes the main fix: preventing dash-prefixed text that contains colons but is not a known prefix keyword from being tokenized as negation. It directly corresponds to the core change in the codebase.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@devteamaegis devteamaegis force-pushed the fix/negate-non-prefix-colon-word branch from 295e6a6 to e353251 Compare June 11, 2026 19:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@devteamaegis