fix(ngsiem): surface LogScale's real syntax errors in validate-query

[willwebster5]

validate-query could only ever emit no detail returned by API — even though the API returns a complete diagnostic with named error codes and caret positions. Two independent defects stacked; fixing either alone is not enough.

Before / after

INVALID: LogScale rejected query (status=400, no detail returned by API)

INVALID: LogScale rejected query (status=400):
Function calls are not supported in filter expressions.
See https://library.humio.com/data-analysis/syntax-filters.html for more information about filters. (Error: FunctionCallsNotSupportedInFilterExpressions)
 2: | NOT (in(field="ContextBaseFileName", values=["a","b"]) #event_simpleName="…
           ^^

Defect 1 — we read a key that is never present

test_query_syntax read response.get("body"). But NGSIEM.start_search() pops it:

# falconpy/ngsiem.py
returned = process_service_request(..., operation_id="StartSearchV1", ...)
if "body" in returned:
    returned["resources"] = returned["body"]
    returned.pop("body")

Verified against a raw falconpy.ngsiem.NGSIEM instance (no wrapper), on both a 200 and a 400 — keys are ['status_code', 'headers', 'resources']. Hosts.query_devices_by_filter() returns body as normal, so the rename is specific to this one method.

So response.get("body") was always {}, errors was always None, and the passthrough the docstring promised was dead code that had never fired.

Now reads resources with body as fallback — the Uber class (command(operation="StartSearchV1")) does not rename, so both shapes occur depending on invocation style. This is also why it's a fallback rather than a swap.

Defect 2 — the useful detail never reaches the SDK caller

LogScale serves syntax errors as text/plain. falconpy only parses application/json; on JSONDecodeError it assumes the body was empty — the comment reads "No response content, but a successful request was made" — and raises NoContentWarning without ever reading response.text. The caller receives a fabricated:

{"errors": [{"message": "No content was received for this request."}]}

That message is the SDK's invention and states the opposite of what happened: Content-Length was 1,382. It sends authors looking at connectivity when the problem is a specific column.

So fixing defect 1 alone would only have upgraded us to surfacing that fabrication. _raw_syntax_error() re-issues the rejected query using the token and base_url falconpy already authenticated (client.auth_object), and reads the text body directly — no second OAuth round trip, no duplicated credential handling. It is best-effort: any failure returns None and we degrade to the previous status-only message.

Output path

console.print now passes markup=False and soft_wrap=True. Both are required: CQL is full of square brackets, which rich parses as style tags (values=["a","b"] would be mangled), and wrapping breaks the caret alignment that makes the diagnostic worth having.

Testing

The existing tests mocked a body key — a shape this endpoint never returns. That mismatch is precisely why the dead passthrough went unnoticed. They're kept, since the Uber class does return body and both shapes must work, and paired with explicit resources coverage.

5 new tests: the resources-key regression, raw diagnostic preferred over the SDK fabrication, caret alignment preserved verbatim, no extra request on the 200 path, and graceful degradation when the bypass fails.

865 passed, ruff check clean, ruff format --check clean.

Verified live against US-2 on three real queries — if() with a regex condition, in() inside NOT (...), and a valid control. Note the test suite must be run with PYTHONPATH=./src; the editable install in this environment resolves to a worktree, so a plain pytest run silently tests different source.

Follow-up

The upstream falconpy behaviour is worth reporting separately — it affects every consumer, including CrowdStrike's own falcon-mcp, whose common/errors.py reads only body.errors with no text/plain path and works around the missing diagnostics with a static CQL hint blob. Once the SDK stops discarding non-JSON bodies, _raw_syntax_error() can be deleted.

Why this matters

This turns validate-query from a pass/fail gate into a real CQL linter. The FunctionCallsNotSupportedInFilterExpressions error above is a live example: diagnosing that one in the detections repo meant guessing at a rewrite, when the API had already named the rule and pointed at the token.

---

Second commit: build(dev): pin ruff <0.16

The lint job failed on the first push. It was not caused by this change — CI resolves ruff>=0.8.0 to the newest release, now 0.16.2, which widened the default rule set and changed formatter output.

Measured with ruff 0.16.2:

	lint errors
master, unmodified	1,378
this branch	1,379
ruff format --check	2 files would be reformatted

master's CI is green only because it last ran 2026-06-29, before 0.16 shipped. Re-run it today and it fails identically. The breakage arrived on ruff's release schedule, not on a commit, and landed on whichever PR happened to be open.

My new test file is clean even under 0.16.2, so nothing here is being papered over.

Pinned to >=0.8.0,<0.16, verified in a clean venv (resolves to 0.15.22 today):

ruff check  src/ tests/ --exclude src/talonctl/_version.py  -> All checks passed!
ruff format --check ...                                     -> 134 files already formatted

A version bound rather than an explicit lint.select, because rule selection would not address the formatter change that fails the second CI step.

The 0.16 findings are largely legitimate — import ordering, Optional[X] → X | None — and worth adopting. But that is a ~1,378-finding migration across most of the tree and deserves its own PR rather than being buried here. Raise the bound there.