Fix LogScale query snippet that could never issue a request - #75
Merged
Conversation
The run_logscale_query helper in the LogScale/NG-SIEM section had two independent bugs that together made it always return None. First, it passed the query payload as body=. FalconPy's start_search gates the request on a search kwarg that it reads only from kwargs, so body= leaves the guard unsatisfied and returns a locally-generated error without ever calling the API. The docstring does list body as accepted, so this is arguably an SDK bug as well (reported as CrowdStrike/falconpy#1491), but search= is what works on shipped versions. Second, it read the job id from started["body"]. On success start_search renames its response payload to "resources", so that key is always absent and job_id was always None even when the call succeeded. get_search_status does not perform the same rename, so the polling code below it was already correct — added comments noting the asymmetry since it is surprising. Also added a keyword-gotcha subsection covering both issues, and corrected the NGSIEM scope row: it claimed the scope was verified against FalconPy source, but FalconPy contains no scope strings at all, so the SDK cannot verify a scope. Marked it inferred from the endpoint path until a sample app confirms it. Verified against FalconPy 1.6.3, 1.6.4, and main/dev. test-hooks.sh: 182/182 pass.
The validate job enforces a 5500-token budget per skill and my additions pushed functions-falcon-api to 5516 (100%). Condensed the keyword-gotcha prose and the inline code comments without dropping any of the substance: the search= requirement, the resources/body asymmetry, and the upstream issue link are all still there. Now at 5418 tokens (98%), leaving some headroom.
Ran the corrected snippet against a real US-2 CID: start_search(search=payload) returns 200 with a job id, polling completes, and the query returns events. That confirms humio-auth-proxy:read is the right scope for start_search / get_search_status, so the row no longer needs to hedge that it was inferred from the endpoint path.
prvn
previously approved these changes
Jul 30, 2026
The 1.4.0 LogScale entry described the recipe without mentioning the two constraints that make it actually work, and claimed the scope came from the reference table without saying how it was confirmed. Corrected in place rather than adding a Fixed entry, since 1.4.0 has not shipped — the broken recipe was never released. Added two content tests pinning the corrected calls. The existing tests only checked that start_search and get_search_status were mentioned somewhere, which is why the bug passed CI in the first place. The new ones assert the search= keyword and the resources key, and both fail against the pre-fix file — verified by reverting the skill and re-running. pytest: 84 passed. test-hooks.sh: 182/182.
mraible
enabled auto-merge (squash)
July 30, 2026 16:13
prvn
approved these changes
Jul 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
run_logscale_queryhelper in the LogScale / NG-SIEM Queries section could never issue a request. Two independent bugs, both verified against FalconPy 1.6.3 and 1.6.4.Wrong keyword. The snippet passed the query payload as
body=. FalconPy'sstart_searchgates the request on asearchkwarg that it reads only fromkwargs, sobody=leaves the guard unsatisfied and returns a locally-generated error without calling the API:bodyis documented as accepted, so this is arguably an SDK bug too — reported as CrowdStrike/falconpy#1491. Either waysearch=is what works on shipped versions.Wrong response key. The snippet read the job id from
started["body"]. On successstart_searchrenames its response payload toresources, so that key is always absent andjob_idwas alwaysNoneeven after a successful call.get_search_statusdoes not perform the same rename, so the polling code below was already correct — added comments noting the asymmetry, since it's surprising.Net effect: a reader following the recipe got a helper that always returned
None, with an error message complaining about a missingrepositoryargument they had in fact supplied.Also in this PR:
search=Keyword Gotcha" subsection documenting both behaviors and linking the upstream issueNGSIEMscope row, which claimedhumio-auth-proxy:readwas "Verified against FalconPy source." FalconPy contains no scope strings at all — only endpoint paths and operation IDs — so the SDK cannot verify a scope. Now marked as inferred from the endpoint path until a sample app confirms it.Verification
Ran the same query both ways against a live CID:
start_search(repository="search-all", body=payload)500—"You must provide a repository and search arguments", generated locally, no HTTP request madestart_search(repository="search-all", search=payload)200— returns a job idOn the successful response
"resources"is present and"body"is absent — exactly why the oldstarted["body"]read always yieldedNone. Polling withget_search_statusthen completed and returned event rows, confirming the asymmetry between the two methods is real and that the corrected helper works end to end.Since the query actually succeeded,
humio-auth-proxy:readis confirmed as the correct scope for these two methods; the scope-table row now says verified rather than inferred../test-hooks.sh— 182/182 pass. Thevalidatejob enforces a 5500-token-per-skill budget and the first push hit 5516, so the gotcha wording and code comments were condensed; now 5414 (98%) with the substance intact.